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ELECTRONIC PROPOSAL PREPARATION SYSTEM 




FIELD OF THE INVENTION 
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The present invention relates to a system for creating a customized proposal by 
linking together product pictures, environment pictures showing environments in which 
the product may be used, and text related to the product. The system includes means 
for linking together predetermined product pictures, environment pictures, and text 
based upon a potential customer's answers to predetermined queries. 

BACKGROUND AND SUMMARY OF THE INVENTION 
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Many products, such as cars, are illustrated to customers by preprinted brochui 
Car dealerships, for example, have glossy brochures that show pictures of cars and 
generic textual descriptions of the cars. A customer may test drive and actually inspect 
a particular car of interest. The dealership will also furnish the customer with one of 
the preprinted brochures of the car. The brochure documents and contains information 
about the car. The customer may refer to the brochure and potentially be quite 
influenced by it in making a decision regarding whether to purchase the car. 

The generic nature of these preprinted brochures, however, may have a negative 
impact on the customer's ultimate decision of whether to purchase and thus are often not 
persuasive. Traditionally, only one brochure is available for each car, for example, and 
every potential purchaser of that car receives the same brochure. These brochures 
contain glossy photographs of the car in a variety of settings, which may include, for 
example, a country setting, city environment, golf course, and marina. Next to the 
photographs, the brochures usually contain generic textual descriptions of the car or 
potential uses of the car. Finally, the brochures typically contain standard lists of 
options for the car along with complex pricing charts from which one may calculate a 
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price based on a matrix of options and prices. 

The preprinted brochures contain all of these different settings for the car and 
generic information in an attempt to appeal to any potential purchaser. For example, 
one customer may enjoy golfing, and the brochure contains a photograph of the car at a 
golf course to appeal to that customer and influence that customer in his or her decision 
to purchase the car. Another customer may want to use the car to take long trips which 
pass through the country, and the photograph in the brochure of the car in a country 
setting is designed to appeal to that customer. 

The brochures also contain standard pricing charts. Since every brochure is 
generic to any customer, however, it must contain complex pricing charts that include a 
matrix of options and prices. Furthermore, since prices of the car or options often 
change, the information in the brochure can easily be out of date. Also, much of the 
pricing information is not of interest to a particular customer, since the customer will 
typically be interested in the price for a single, or relatively few, combinations of 
options for the car. 

In containing all of this varied and generic information in an attempt to be "all 
things to every customer," the preprinted brochures actually are of limited value to any 
particular customer. The brochures are not customer specific and, therefore, are not 
particularly appealing or persuasive for any customer. The typical brochure contains 
much information that is of no value or interest to a particular customer due to the 
varied and generic nature of the product pictures and textual descriptions. Furthermore, 
these preprinted brochures are expensive to produce because of the glossy photographs 
and may be quickly out of date, meaning that either a dealership must discard the 
brochures or provide customers with "old" brochures. 

The present invention solves these problems by utilizing a computer-based system 
to dynamically create customized, printed proposals for potential purchasers of a 
product. The system queries a customer to determine his or her interests and desired 
options. The interests may include a "use" desired by the customer, such as a marina or 




golf course. The interests may also include the type of information, such as technical, 
that the customer would like in the proposal. The desired options may include the 
various features of interest to the customer, such as the type of engine desired. 

Based upon the customer's answers to the queries, the system links product 
pictures, environment pictures, and textual descriptions together in a customized 
proposal. The system also has the capability to link together other aspects in the 
proposal, which may include environment text describing the product in a particular 
setting or environment. The customized proposal, therefore, contains pictures, textual 
descriptions, and pricing information that is all of interest to and relevant to a specific 
customer, since all of the pictures and text were linked together based upon the 
customer's answers. 

Since each proposal is customized for a particular customer, each proposal will 
have a much more persuasive effect in selling the product. Also, if any information 
about the product changes, such as prices of options, the system information stored in a 
data base may be simply changed in order to accommodate the new information. 
Additional textual descriptions or pictures may also be added to the system data base to 
be used in linking together information for a proposal. 

The quality of the pictures produced in these customized, printed proposals can be 
made comparable in quality to the glossy photographs in prior art proposals due to 
recent advances in computer printers. Printers such as the Canon CLC-300 produce 
color computer print -outs that resemble color photographs. These customized proposals, 
therefore, need not be inferior to prior art proposals in terms of the quality of available 
pictures for the proposals. 

This system for producing customized, high-quality proposals has many potential 
applications, such as in the car industry. A customized proposal generated by the 
present invention will have a great appeal to each individual customer and will be an 
asset in selling the product. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1A is a block diagram illustrating conceptually picture and text databases of the 
computerized proposal system. 

FIG. IB is a diagram illustrating conceptually an electronic proposal template of the 
computerized proposal system. 

FIG. 2 is a block diagram showing the preferred system. 

FIG. 3 is an object diagram showing an active database. 

FIG. 4 is a class diagram showing a detailed depiction of the classes in a preferred 
proposal data class. 

FIG. 5 is an object diagram showing a detailed depiction of a preferred table of 
contents object. 

FIG. 6 is a class diagram showing a detailed depiction of the classes in a preferred 
customize data class. 

FIG. 7 is an object diagram showing a user interface. 

FIG. 8 is a class diagram showing a detailed depiction of the classes in a preferred 
form class. 

FIG. 9 is a block diagram showing the contents of a static database. 

FIG. 10 is a block diagram showing a detailed depiction of the elements in a 
preferred report generator. 

FIG. 11 is a block diagram showing a detailed depiction of the elements in a 
preferred selection device. 

FIG. 12 is a detailed depiction of the elements in a preferred main menu. 

FIG. 13 is a detailed depiction of the elements within the "Contents" selection of the 
preferred main menu. 

FIG. 14 is a block diagram showing the contents of a difference database. 

FIG. 15 is a block diagram showing the contents of a report database. 

FIG. 16 is an object diagram showing a detailed depiction of the elements in a 



preferred user interface. 

FIG. 17 is an object diagram showing a detailed depiction of the elements in an 
active database. 

FIG. 18 is an object diagram illustrating a preferred flow of control involved when 
selecting pages to print. 

FIG. 19 is an object diagram illustrating a preferred flow of control involved when 
generating a cover sheet. 

FIG. 20 is an object diagram illustrating a preferred flow of control involved when 
entering customer identification data. 

FIG. 21 is an object diagram illustrating a preferred flow of control involved when 
generating customer identification data. 

FIG. 22 is an object diagram illustrating a preferred flow of control involved when 
entering salesperson identification (Jata. 

FIG. 23 is an object diagram illustrating a preferred flow of control involved when 
generating salesperson identification data. 

FIG. 24 is an object diagram illustrating a preferred flow of control involved when 
entering letter information. 

FIG. 25 is an object diagram illustrating a preferred flow of control involved when 
generating a personalized letter. 

FIG. 26 is an object diagram illustrating a preferred flow of control involved when 
selecting product descriptions. 

FIG. 27 is an object diagram illustrating a preferred flow of control involved when 
generating product description pages. 

FIG. 28 is an object diagram illustrating a preferred flow of control involved when 
entering product specification information. 

FIG, 29 is an object diagram illustrating a preferred flow of control involved when 
generating product specification pages. 

FIG. 30 is an object diagram illustrating a preferred flow of control involved when 



generating performance specification pages. 

FIG. 31 is an object diagram illustrating a preferred flow of control involved when 
entering trade-in product information. 

FIG. 32 is an object diagram illustrating a preferred flow of control involved when 
generating trade-in product pages. 

FIG. 33 is an object diagram illustrating a preferred flow of control involved when 
entering product price quotation information. 

FIG. 34 is an object diagram illustrating a preferred flow of control involved when 
generating product price quotation pages. 

FIG. 35 is an object diagram illustrating a preferred flow of control involved when 
entering product financing information. 

FIG. 36 is an object diagram illustrating a preferred flow of control involved when 
entering product financing pages. 

FIG. 37 is an object diagram illustrating a preferred flow of control involved when 
entering life cycle cost information. 

FIG. 38 is an object diagram illustrating a preferred flow of control involved when 
generating life cycle cost pages. 

FIG. 39 is an object diagram illustrating a preferred flow of control involved when 
generating a table of contents page. 

FIG. 40 is an object diagram illustrating a preferred flow of control involved when 
printing a trademark. 

FIG. 41 is an object diagram illustrating a preferred flow of control involved when 
choosing a language. 

FIG. 42 is an object diagram illustrating a preferred flow of control involved when 
generating a signature page. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 



The present computer system is preferably implemented using Object Oriented 
Design (OOD). Because OOD is a fairly new programming method, a brief explanation 
of OOD design concepts will be offered here in order to ensure a better understanding. 
The resource used for preparing this explanation is: Grady Booch, Object Oriented 
Design with Applications (1991) (published by The Benjamin/Cummings Publishing 
Company, Inc.). 

According to Booch, the Object Oriented Design methodology views the "world" as a 
set of autonomous agents that collaborate to perform higher level behavior. The OOD 
agents are called objects. Objects can have a state, behavior and identity. A set of 
objects that share a common structure and common behavior are called a class. A set of 
objects working together to provide; a behavior that satisfies some requirement of a 
problem is called a mechanism. 

The design described herein is an object-oriented design. This design is described 
using object diagrams which show the interaction of the objects that make up the 
application. In addition, class diagrams are used to present the architecture of the 
system. 

Unless otherwise stated, all classes making up the architecture of the system 
preferably are derived from a common base class named CWCObject. Where this is not 
the case, class diagrams are used. 

INTRODUCTION 

FIGS. 1A and IB illustrate conceptually a primary feature of the computerized 
proposal system. The system allows a user to dynamically customize and create a 
proposal for individual customers. The customized proposal may contain specific items 
for a particular customer, depending upon the customer's needs and desires. FIG. 1A 



shows conceptually a database 50 that electronically stores a plurality of pictures. The 

pictures may include environment pictures 51-55, product pictures 56, and pictures for 

various parts 57 and 58. A textual descriptions database 59 may store a plurality of text 

segments that correspond to various pictures in the picture database 50. 

♦ 

FIG. IB illustrates conceptually an electronic template for creating a page in a 
customized proposal. The system may query a user to determine a particular customer's 
needs and interests. Based upon the answers to the queries, the system may "fill in" the 
template 60 to customize a proposal for the customer. For example, if the customer has 
an interest in sailing or boating, the system may choose a picture of a marina 
environment 51 to use as the background or environment 62 in picture 61 of template 
60. Likewise, if the customer has an interest in golfing, the system may choose a golf 
course environment 52. Within the environment 62, the system places a product 63 by 
selecting one of the plurality of product picture 56 based upon the customer's answers. 

Each product 63 typically has several options available to the customer, such as the 
type of engine and wheels. Based upon the customer's answers, which indicate the 
customer's desired options, the system may select parts from the picture database 50 for 
parts 64 and 65 on product 63 in the template. The system may also select one of the 
plurality of text segments 59 to fill in text frame 66. The text in the text frame 66 
would typically correspond to picture 61 and, for example, provide a description of the 
product or its performance specifications. 

Accordingly, the system uses the stored pictures in the picture database 50 as 
building blocks for filling in the template. The system establishes a customer profile 
based on the customer's answers to queries. The system then uses the profile to "build" 
the empty frames, such as picture 61, in template 60. 

The approach of using picture building blocks provides for much versatility and 
the capability to customize a proposal. Products may be shown in any one of a variety 
of environments by simply selecting the appropriate picture building blocks. Likewise, 
any combination of options may be shown on a particular product by selecting the 
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appropriate part picture building blocks. Each combination of pictures for a finished 
template need not be pre -stored, since the system dynamically builds a template. Also, 
the system provides further advantages by allowing easy change of options. For 
example, if a particular type of wheel is no longer available on a truck, a user may 
simply change the stored picture for that wheel. Options may easily be changed by 
loading and storing new part pictures in the picture database. The system, therefore, 
provides for customized proposals that are up-to-date and may accommodate changes in 
available options. For simplicity, the system has been conceptually shown with a 
product in an environment. One skilled in the art will recognize that the system is 
capable of creating different types of templates or proposals based on different picture 
building blocks or different combinations of the building blocks. 

OVERVIEW 

Referring now to FIG. 2, a computer system 100 is shown. Preferred computer 
system 100 incorporates an active database 103, a static database 105, a report database 
106, a user interface 102, a selection device 101, and a report generator 104. The 
computer system 100 may also incorporate a difference database 107, The selection 
device 101 is operatively interconnected to the active database 103, to the report 
database 106, to the report generator 104, and to the user interface 102. The active 
database 103, the report database 106, the static database 105, and the difference 
database 107 are operatively interconnected to the report generator 104. 

Referring now to FIG. 2 in combination with FIG. 3 and FIG. 4, the active database 
103 may electronically store proposal- related customer information in the proposal 
object 110. A proposal object 110 is an instance of the proposal class which is itself 
derived from the CWCObject class. The active database 103 may contain a plurality of 
proposal objects 110. Each proposal object 110 may contain a plurality of ProposalData 
objects 112. The ProposalData objects 112 may store customer- related information 




collected by the user. ProposalData objects 112 are instances of the ProposalData class 

320 which is derived from the CWCObject class. 

Customer -related information may be entered interactively via the user interface 102 

typically beginning at the time the program is first started, and may continue to be 
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entered intermittently throughout the time the program is running. Referring now to 
FIG. 7, in combination with FIG. 3, FIG, 16, and FIG. 17, the user-entered information 
may be gathered on one or more of the various Form objects 118, and then stored in one 
or more of the various ProposalData objects 112 in the proposal 110 in the active 
database 103. 

Table 1 shows how information is stored in a preferred embodiment: the first 
column indicates the type of information stored; the second column indicates the 
corresponding object by which a user may enter the information; the third column 
indicates the corresponding class of which the object is an instance; and the fourth 
column indicates the corresponding form class from which the class in the third column 
is derived. The classes are identified in the table by reference numerals and preferably 
have the same identifying label as the objects to which they correspond. For example, 
reference numeral 361 in table 1 refers to the TradeForm class 361. 



Table 1 

Type of 

Information Object Class Form Class 



trade-in product 


TradeForm Object 292 


361 


340 


product price quotation 


QuotationForm object 294 


362 


340 


financing a product 


FinanceForm object 296 


364 


340 


product life cycle cost 


LifeCycleForm object 298 


366 


340 


personalized letter 


LetterForm object 288 


358 


340 


product 


ProductForm object 290 


360 


340 


customer 


CustomerForm object 286 


356 


340 
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table of contents 

salesperson 

to save a proposal 

to recall a stored 
proposal 

language 

dealer 

password 



TableOfContentsForm 354 
object 284 

ListOfSalesPersonsForm 352 
object 310 

SaveProposalForm 

object 308 350 

RecallProposalForm 

object 306 348 

LanguageForm object 304 346 

DealerForm object 302 344 

PasswordForm object 300 342 



340 
340 

340 

340 
340 
340 
340 
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20 Objects of classes derived from a common base class can be referred to as if they 

were objects of the common base class due to the principle of polymorphism. The 
TradeForm object 292 can therefore be treated generically as a Form object 118. The 
user interface 102 typically comprises a collection of such Form objects 118, each of 
which can be made to load itself into a window on the computer screen. 

25 Table 2 shows how information gathered by the various objects described above may 

be stored as data objects in a preferred embodiment: the first column indicates the type 
of information stored; the second column indicates the corresponding data object in 
which the information may be stored; the third column indicates the corresponding data 
class of which the data object is an instance; and the fourth column indicates the 

30 corresponding clasL from which the data class in the third column is derived. The data 
classes are identified in the table by reference numerals and preferably have the same 
identifying label as the data objects to which they correspond. For example, reference 
numeral 380 in Table 2 refers to the TradeData class 380. 

Each of the listed data objects in Table 2 may preferably be treated generically as a 

35 ProposalData object 112 and stored as one of the various ProposalData objects 112 in the 
proposal object 110. 
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Table 2 


Type of 
Information 


Data Object 


Data Class 


Class 


trade-in product 


TradeData Object 142 


380 


320 


product price quotation 


QuotationData object 144 


382 


320 


financing a product 


FinanceData object 146 


384 


320 


product life cycle cost 


LifeCycleData object 148 


386 


320 


personalized letter 


LetterData object 138 


376 


320 


product 


ProductData object 140 


378 


320 


customer 


CustomerData object 136 


374 


320 


cover sheet 


CoverSheetData object 132 


372 


320 


table of contents 


TableOfContentsData 
object 130 


368 


320 


salesperson 


SalesPersonData 
object 134 


370 


320 



Referring now to FIG. 2 in combination with FIG. 3, FIG. 6, FIG. 16, and FIG. 17, 
the active database 103 may electronically store dealer, salesperson, and language 
information in the customized database 114. A customized database 114 is an instance 
of the CustomizeDataBase class which is itself derived from the CWCObject class. The 
active database 103 may contain a plurality of customized database 114. Each 
customized database 114 may contain a plurality of CustomizeData objects 116. The 
CustomizeData objects 116 typically store dealer, salesperson, and language information. 

Table 3 shows how information gathered by the various objects described above may 
be stored as data objects in a preferred embodiment: the first column indicates the type 
of information stored; the second column indicates the corresponding data object in 
which the information may be stored; the third column indicates the corresponding data 
class of which the data object is an instance; and the fourth column indicates the 
corresponding class from which the data class in the third column is derived. The data 
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classes are identified in the table by reference numerals and preferably have the same 
identifying label as the data objects to which they correspond. For example, reference 
numeral 390 in Table 3 refers to the DealerData class 390. 

Each of the listed data objects in Table 3 may preferably be treated generically as a 
CustomizeData object 116 and stored as one of the various CustomizeData objects 116 in 
the customized database 114. 



Table 3 


Type of 
Information 


Data Object 


Data Class 


Class 


dealer 


DealerData object 156 


390 


330 


salesperson 


ListOfSalesPersonsData 
object 158 


392 


330 


language 


LanguageData object 160 


394 


330 


password 


PasswordData object 164 


396 


330 



The dealer, salesperson and language information may be restricted using a password 
entry system. 

Referring now to FIG. 2 in combination with FIG. 9, the static database 105 may 
electronically store the following: a plurality of environment pictures 122, and a 
plurality of environment text 124, both of which are related to the environment in 
which the product may be used; a plurality of product pictures 126, and a plurality of 
product text 128, both of which are related to features and benefits of the product; a 
plurality of product specifications 121 which relate to the technical details of the 
product; a plurality of price specifications 125 which determine the price of the product; 
a plurality of performance specifications 123 which represent the performance of the 
product; a plurality of trademark pictures 127 which identify the product; a plurality of 
product descriptions 131 which describe the various products; and a plurality of life 
cycle specifications 129 which determine the projected cost involved in owning the 
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product. The static database 105 may be stored on optical media. The contents of the 
static database 105 preferably cannot be altered by the user of this application. Changes 
to the static database 105 may be distributed to some or all of the users of this 
application on either optical or magnetic media. 

Referring now to FIG. 2, in combination with FIG. 14, the difference database 107 
may electronically store the updates to the static database 105. If the static database 105 
is stored on optical media, a difference database 107, stored on magnetic media, may be 
used to store information that reflects net changes to the contents of the static database 
105. In the event that updates are required for the computer system, these updates are 
typically stored on magnetic media and sent to all the various owners of the system who 
will want to update the contents of the static database 105. The difference database 107 
may be used to store the updates to the following: the plurality of environment pictures 
122; the plurality of environment text 124; the plurality of product pictures 126; the 
plurality of product text 128; the plurality of product specifications 121; the plurality of 
price specifications 125; the plurality of performance specifications 123; the plurality of 
trademark pictures 127; the plurality of product descriptions 131; and the plurality of 
life cycle specifications 129. 

Referring now to FIG. 2, in combination with FIG. 15, the report database 106 may 
electronically store a plurality of page layouts 120 which are used to format and produce 
the various pages of information available for inclusion in the printed proposal. 

Referring now to FIG. 2, when the user begins a deal with a customer, the user will 
typically want to gather specific customer and product information regarding this 
individual customer and the product this customer is interested in purchasing. The user 
interface 102 is the means by which the user may interactively input predetermined 
answers to predetermined queries, the predetermined answers corresponding to the 
individual customer who is to receive the proposal. 

Referring now to FIG. 2 in combination with FIG. 7 and FIG. 16, the user interface 
102 typically comprises a collection of Form objects 118 which present a series of 
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predetermined queries related to the varying interests of the different potential 
customers. The proposal -related information entered interactively by the user on the 
various Form objects 118 preferably can be altered at any time by the user. 

Referring now to FIG. 2, in combination with FIG. 7, FIG. 8, and FIG. 11, the user 
interface 102 may also control operation of the selection device 101 via the main menu 
170 of the selection device. The main menu 170 would typically include choices that 
prompt the selection device 101 to send a message to a particular Form object 118 
requesting that it display itself. 

Referring now to FIG. 12, when the user is first beginning to deal with a customer, 
the user will typically need to start a new proposal. The user may select Tile" 172 from 
the main menu 170. Note that labels identifying menu choices may be altered in 
customized versions of this application designed for different users. The "File" menu 
172 contains the option "New Proposal" 186, which the user selects when beginning to 
deal with a new customer. After the user has begun a new proposal, the information for 
this new proposal may be stored by selecting "Save Proposal..." 190 from the "File" menu 
172. After a proposal has been stored, the user can modify the stored proposal by 
selecting the option "Recall proposal..." 188 from the "File" menu 172. 

Referring now to FIG. 11 in combination with FIG. 8 and FIG. 12, the user may 
select "Customer Information" 176 from the main menu 170, which opens a window with 
choices pertinent to customer and product information. These pertinent choices 
correspond to the various Form objects 118, upon which the user enters information 
pertaining to this particular customer and the product the customer is interested in 
purchasing. 

Referring now to FIG. 12 in combination with FIG. 3, FIG. 4, FIG. 7, and FIG. 8, 
the user may select "Customer Information" 176 from main menu 170, then further select 
"Customer..." 198, which opens the CustomerForm object 286. The user may enter 
customer information via the CustomerForm object 286, which is then preferably stored 
in the CustomerData object 136 which is one of the ProposalData objects 112 in the 




proposal object 110 in the active database 103. The user may select "Letter..." 202 from 
"Customer Information" 176 and then enter information via the LetterForm object 288, 
which is then preferably stored in a LetterData object 138 as one of the ProposalData 
objects 112 in the proposal object 110. In this same fashion, the user may select 
"Standard and Optional Equipment..." 204 from "Customer Information" 176, and then 
enter information via the ProductForm object 290, which is then preferably stored in a 
ProductData object 140 as one of the ProposalData objects 112 in the proposal object 
110. The user may select "Trade..." 206 from "Customer Information" 176, and then 
enter information via the TradeForm object 292, which is then preferably stored in a 
TradeData object 142 as one of the various ProposalData objects 112 in the proposal 
object 110. In a similar fashion, the user may select "Quotation..." 208 from "Customer 
Information" 176, and then enter information via the QuotationForm object 294, which 
is then preferably stored in a QuotationData object 144 as one of the various 
ProposalData objects 112 in the proposal object 110. The user may select "Payment 
Schedule & Terms..." 210 from "Customer Information" 176, and then enter information 
via the FinanceForm object 296, which is then preferably stored in a FinanceData object 
146 as one of the ProposalDatas objects 112 in the proposal object 110. The user may 
select "Economics..." 212 from "Customer Information" 176, and then enter information 
via the LifeCycleForm object 298, which is then preferably stored in a LifeCycleData 
object 148 as one of the various ProposalData objects 112 in the proposal object 110. 

Referring now to FIG. 12 in combination with FIG. 3, FIG. 6, FIG. 7, and FIG. 8, 
the owner of the dealership, for example, may select the "Customize" menu 177 from 
main menu 170, then further select "Passwords..." 224, which opens the PasswordForm 
object 300. The owner enters dealer and salesperson password information via the 
PasswordForm object 300, which is then stored in a PassWordData object 164 as one of 
the various CustomizeData objects 116 in the customized database 114 in the active 
database 103. The owner may select "Dealer Name..." 226 from the customized menu 
selection 177 and then enter information via the DealerForm object 302, which is then 
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preferably stored in a DealerData object 156 which is one of the CustomizeData objects 
116 in the CustomizeDataBase 114. The user may select "Dealer Information..." 228 from 
the customized menu selection 177 and then enter salesperson information via the 
ListOfSalesPersonsForm object 310, which is then preferably stored in a 
ListOfSalesPersonsData object 158 which is one of the CustomizeData objects 116 in the 
CustomizeDataBase 114. In this same fashion, the user may select "International..." 234 
from the customized menu selection 177, and then choose a language on the 
LanguageForm object 304, which is then preferably stored in a LanguageData object 
160 which is one of the CustomizeData objects 116 in the customized database 114. 

Computer system 100 may further be enhanced by the addition of a report generator 
104. Referring now to FIG. 2, in combination with FIG. 10, the report generator 104 
includes mechanism 262 which comprises means for processing and generating the 
customized, printed proposal. The report generator 104 may be operatively 
interconnected to the active database 103, to the static database 105, to the report 
database 106, to the selection device 101, and to the user interface mechanism 102. 

The user may decide to generate a customized, printed proposal to an individual 
customer relating to the individual customer's interest in a product, the product being 
characterized by a variety of distinctive features. The customized, printed proposal may 
include one or more pages comprising the information collected during the process of 
dealing on the purchase of the product. 

Referring now to FIG. 2, in combination with FIG. 10, and FIG. 11, the user may 
want to generate a printed proposal. In order to do so, the user will typically first need 
to design a table of contents for the proposal, which entails selecting the individual 
pages that will be included. Using selection device 101, the user may select 
"Contents...!* 174 from the main menu 170. In response, the selection device 101 
preferably sends a load message to the TableOfContentsForm object 284, as shown in 
FIG. 7, in combination with FIG. 16. On receipt of the load message, the 
TableOfContentsForm object 284 displays itself within the main window of the selection 
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device 101, as shown in FIG. 13. 

Referring now to FIG. 16, in combination with FIG. 7, FIG. 3, and FIG. 17, upon 
loading itself, the TableOfContentsForm object 284 may obtain a pointer to the proposal 
object 110, from which the TableOfContentsForm object 284 then obtains a pointer to 
the TableOfContentsData object 130. 

Referring now to FIG. 13, the user selects the desired proposal pages, referred to as 
the current publication 260, from a list of pages, referred to on-screen as "Table of 
Contents" 196, that are available for inclusion in the printed proposal. As the user 
selects the desired pages from "Table of Contents" 196, these pages then preferably list 
themselves on-screen under the heading "Current Publication." The selected pages, 
"Current Publication" 260, may be stored as PageDescription records 314 in the 
TableOfContentsData object 130, as shown in FIG. 5. (The contents of the pages to be 
printed are typically not stored; only the page description records describing the pages to 
be printed are stored.) 

Referring now to FIG. 13, in combination with FIG. 15, and FIG. 5, the 
PageDescription records 314 may each include a field that contains an identifier that 
indicates which page layout 120 may be used to format each page in the current 
publication 260. The page layout 120 determines the content and appearance of the 
final printed page. 

Referring now to FIG. 10, in combination with FIG. 15, and FIG. 5, the report 
generator 104 includes a mechanism 268 for reading the page description records 314. 
The report generator 104 typically includes a mechanism 270 for reading the page layout 
identifiers. The page layout identifiers may indicate which page layouts 120 are to be 
used to format the particular pages. The page layout identifiers may specify which 
particular data is required, and also specify where that particular data will appear on the 
printed page. The report generator 104 provides a mechanism 285 for linking the page 
layout identifiers with the particular data that is to appear on the printed page. The 
report generator 104 typically includes a mechanism 276 for placing the retrieved data in 
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the appropriate locations on the page as described in the page layout. 

Referring now to FIG. 2, in combination with FIG. 12, the user may decide to print 
the customized proposal for an individual customer. The user preferably selects "Print" 
178 from the "File" menu 172, and further selects "Proposal" 218. The selection device 
101 then sends a print request to the report generator 104. 

Referring now to FIG. 10, in combination with FIG. 2, FIG. 3, and FIG. 9, the 
report generator 104 may include a mechanism 264, which queries the active database 
103. The report generator 104 may include a mechanism 272 for locating and retrieving 
data from the active database 103. This active data typically includes the customer and 
product information entered by the user via the user interface 102, the information 
which comprises the predetermined answers to predetermined questions, the 
predetermined answers corresponding to the individual customer who is to receive the 
proposal. The report generator 104 preferably provides a mechanism 285 for linking 
these predetermined answers (active data) with the predetermined product pictures and 
text (static data) related to the individual features, benefits and environments that are of 
particular interest to the individual customer. These predetermined pictures and text 
may be obtained from the static database 105. The report generator 104 preferably 
includes the following mechanisms: mechanism 266, which queries the static database 
105; mechanism 274 for locating and retrieving data from the static database 105; a 
dealer personalization mechanism 280 for generating a printed proposal automatically 
customized for a particular dealer; a customer personalization mechanism 282 for 
generating a printed proposal automatically personalized for a particular customer; and 
mechanism 278 for generating a printed proposal in a plurality of colors. For example, a 
generated printed proposal includes high -resolution graphics printed in real-life, 
photographic -quality colors, producing a printed picture of a superior nature that 
enhances the readability as well as the overall appearance of the printed proposal. 

The following is a description of a preferred embodiment of the computerized 
system for generating a customized, printed proposal for an individual customer's 
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purchase of a product. The system as generally described in FIG. 2 through FIG. 17 
will further be detailed in the following discussion and FIG. 18 through FIG. 42. In the 
preferred embodiment discussion that follows, the user may select from several generic 
types of pages to include in the printed proposal. The types of pages typically include 
cover sheets, personalized letters, product description pages, product specification pages, 
performance specification pages, trade-in specification pages, product Price Quotation 
pages, Finance plan pages, Life Cycle evaluation pages, Table of Contents pages, and a 
Signature page. In the preferred embodiment, a Trademark may be printed on any of 
the pages of the proposal, and the proposal may be printed in any one of a plurality of 
languages. 

Proposal: Cover Sheet 

The user may decide to generate a customized, printed proposal that includes a 
cover sheet 250. To include this cover sheet 250, the user may select "Contents" 174 
from the main menu 170 of the selection device 101, as shown by step 18-1 of FIG. 18. 
In response, the selection device 101 preferably sends a load message to the 
TableOfContentsForm object, as shown by step 18-2 of FIG. 18. On receipt of the load 
message, the TableOfContentsForm object displays itself within the main window of the 
selection device 101. Upon loading itself, the TableOfContentsForm object may obtain 
a pointer to the proposal object 110, as shown by step 18-3 of FIG. 18. The 
TableOfContentsForm object then obtains a pointer from the proposal object 110 to the 
TableOfContentsData object 130, as shown by step 18-4 of FIG. 18. The user may then 
select the desired "Cover Page" 250 from a list of pages that are available for inclusion 
in the printed proposal, as shown by step 18-5 of FIG. 18. The selected page may be 
stored as a PageDescription record in the TableOfContentsData object 130, as shown by 
step 18-6 of FIG. 18. This PageDescription record may include a field that contains an 
identifier that indicates which page layout 120 may be used to format the cover sheet 
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250. The page layout 120 determines the content and appearance of the final printed 
page. The page layouts 120 may be stored in the report database 106. 

To initiate the printing of the pages of the cover sheet 250, the user may select 
"Print" 178 from the main menu 170 of the selection device 101, as shown by step 19-1 
of FIG. 19. In response, the selection device 101 preferably sends a print request to the 
report generator 104, as shown by step 19-2 of FIG. 19. The report generator 104 
typically queries the active database 103 for successive page description records that 
describe the pages of the printed proposal, as shown by step 19-3 of FIG. 19. The 
active database 103 processes the request by searching the TableOfContentsData object 
130 located in the current proposal. If the proposal is to include one or more cover 
sheet 250 pages comprising predetermined pictures and text related to features, benefits 
and environments of interest to the customer, the active database 103 preferably queries 
the TableOfContentsData object 130 for the applicable PageDescriptionRecord 314. The 
TableOfContentsData object 130 returns the relevant PageDescriptionRecord 314 to the 
active database 103. The active database 103 may then send the relevant 
PageDescriptionRecord 314 to the report generator 104, as shown by step 19-4 in FIG. 
19. These PageDescriptionRecord 314 may include a field that contains an identifier 
that indicates which page layouts 120 may be used to format these particular cover sheet 
250 pages. The report generator 104 preferably queries the report database 106 for the 
applicable page layouts 120, as shown by step 19-5 in FIG. 19. The report database 106 
may return the relevant page layouts 120 to the report generator 104, as shown by step 
19-6 in FIG. 19. 

Each page layout 120 typically contains formatting specifications that indicate 
where specific cover sheet 250 information may appear on the printed page. The report 
generator 104 reads each format specification to determine the data required at that 
location on the page. 

The report generator 104 retrieves the text and pictures relating to features, benefits 
and environments of particular interest to the customer from the static database 105 
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object, as shown by step 19-9 in FIG. 19. The static database 105 will preferably return 
this information to the report generator 104, as shown by step 19-10 in FIG. 19. The 
report generator 104 typically repeats this process for each format specification on the 
page layout 120, which builds a cover sheet 250 page that may then be sent to the 
printer, as shown by step 19-11 in FIG. 19. In this fashion, the Report Generator 104 
may print one or more customized and individualized cover sheet 250 pages. 

The user interface 102 provides means for inputting the customer identification 
data of the individual customer who is to receive the proposal. The user may select 
"Customer Information* 176 from the main menu 170 of the selection device 101, as 
shown by step 20-1 in FIG. 20. In response, the selection device 101 preferably sends a 
load message to the CustomerForm object 286, as shown by step 20-2 in FIG. 20. On 
receipt of the load message, the CustomerForm object 286 displays itself in a window 
within the main window of the selection device 101. The CustomerForm object 286 
may request a pointer to the current proposal, as shown by step 20-3 in FIG. 20. The 
CustomerForm object 286 typically requests from the current proposal a pointer to the 
CustomerData object 136 for this proposal, as shown by step 20-4 in FIG. 20. 

The CustomerForm object 286 presents a user interface 102 typically comprising text 
entry fields and predetermined questions for the user. The text entry fields allow the 
user to input the name, address, telephone number and other identification data of the 
individual customer who is to receive the proposal, as shown by step 20-5 in FIG. 20. 
The predetermined questions allow the user to select one of a list of predetermined 
answers that correspond to the individual customer who is to receive the proposal. The 
customer information gathered by the CustomerForm object 286 may be stored in a 
CustomerData object 136 within the current proposal, as shown by step 20-6 in FIG. 20. 

The cover sheet 250 page layout 120 may specify that the name, address and 
telephone number or other identification data of the customer appear on the cover sheet 
250. The customer information may be stored in the CustomerData object 136 attached 
to the proposal. 
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The report generator 104 preferably reads format specifications from the page layout 
120 via the report database 106, as shown by step 21-1 in FIG. 21. When the particular 
formatting specification in the page layout 120 requires the customer's name, address, or 
telephone number or other identification data to be included on a printed page, the 
report generator 104 preferably sends a request to the active database 103 for the 
specified customer information, as shown by step 21-2 in FIG. 21. The active database 
103 obtains the specified customer information from the CustomerData object 136 stored 
within the current proposal object 110. The active database 103 then returns this 
information to the report generator 104, as shown by step 21-3 in FIG. 21. The report 
generator 104 preferably builds the page using this information and sends it to the 
printer, as shown by step 21-4 in FIG. 21. 

The user interface 102 may also provide means for inputting the salesperson 
identification data of the salesperson who is dealing with the individual customer. When 
a salesperson first accesses the selection device 101 to begin a proposal for a customer, a 
PasswordForm object is preferably displayed automatically. The salesperson may enter 
his/her name and password using the PasswordForm object 300, as shown by step 22-1 
in FIG. 22. The PasswordForm object 300 typically requests from the selection device 
101 a pointer to the ListOfSalesPersonsData object 158 in the customized database 114, 
as shown by step 22-2 in FIG. 22. The PasswordForm object 300, using this 
salesperson's password may locate the name, address, and telephone number of the 
salesperson, which is stored in the customized database 114, in a ListOfSalesPersons 
object, as shown by step 22-3 in FIG. 22. 

If the salesperson exists in the ListOfSalesPersons object, the selection device 101 
will preferably create a new proposal, which will be the current proposal, as shown by 
step 22-4 in FIG. 22. The PasswordForm object 300 may then obtain a pointer to the 
SalesPersonData object 134 in the proposal, as shown by step 22-5 in FIG. 22. The 
salesperson information may be stored in the SalesPersonData object 134 as a part of the 
current proposal, as shown by step 22-6 in FIG. 22. 
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Salesperson information for all the employees is preferably stored in the customized 
database 114 in a ListOfSalesPersons object. The employer may create an individual 
Salesperson object for each employee. The ListOfSalesPersons object is a data structure 
containing a list of Salesperson objects. 

Dealership information may also be stored in the customized database 114 in the 
DealerName object. The Salesperson object and DealerName object can be created by 
the employer when the system is first purchased. The employer may choose to secure 
these two databases so that only the employer's master password will allow access. These 
data structures may be modified by the employer via the customized menu selection 177 
in the selection device 101. 

The user may choose to modify the name, address, and telephone number of the 
salesperson who is dealing with the individual customer, if the salesperson information is 
not as it should appear in the printed proposal. To modify the salesperson information, 
the user may select the appropriate customized menu selection 177 in the main menu 170 
of the selection device 101. However, access to the customized menu selection 177, that 
allows modification of salesperson information and passwords, may be restricted. If the 
employer has secured this data base, only the employer's master password should allow 
access to the salesperson information. 

The cover sheet 250 page layouts 120 may specify that the name, address and 
telephone number of the salesperson appear on the cover sheet 250. The salesperson 
information is typically initially entered by the employer in the ListOfSalesPersonsData 
object 158 and is stored in the individual salesperson's SalesPersonData object 134 
attached to the proposal. (See FIG. 22). 

The report generator 104 reads format specifications from the page layout 120 via 
the report database 106, as shown by step 1-23 in FIG. 23. When the particular format 
specifiers require the salesperson's name, address and telephone number to be included 
on a page format, the report generator 104 preferably sends a request to the active 
database 103 for the specified salesperson information, as shown by step 2-23 in FIG. 
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23. The active database 103 may obtain this salesperson information from the 
SalesPersonData object 134 in the proposal and returns this salesperson information to 
the report generator 104, as shown by step 3-23 in FIG. 23. The report generator 104 
preferably builds the page using this salesperson information and sends the page to the 
printer, as shown by step 4-23 in FIG. 23. 

Proposal: Personalized Letter 

When the user begins a deal with a customer, the user may want to include a 
personalized letter 254 in the customized, printed proposal that will be prepared for the 
customer. 

The user interface 102 provides means for presenting a series of predetermined 
queries related to writing a letter 254 of interest to different potential customers who 
may purchase a product. The user interface 102 also provides means for inputting 
individualized answers to the predetermined queries, the individualized answers 
comprising a personalized letter 254 relating to product configurations that are of 
particular interest to the individual customer who is to receive the proposal. 

The user may select "Customer Information" 176 from the main menu 170 of the 
selection device 101, as shown by step 24-1 in FIG. 24, The user further selects "Letter" 
202 from the "Customer Information" menu 176. In response, the selection device 101 
preferably sends a load message to the LetterForm object 288, as shown by step 24-2 in 
FIG. 24. On receipt of the load message, the LetterForm object 288 displays itself in a 
window within the main window of the selection device 101. Upon loading itself, the 
LetterForm object 288 may obtain a pointer to a proposal object 110, as shown by step 
24-3 in FIG. 24. The LetterForm object 288 then obtains a pointer from the proposal 
object 110 to a LetterData object 138, as shown by step 24-4 in FIG. 24. 

The LetterForm object 288 preferably presents a user interface 102 to the user 
comprising text entry fields and predetermined questions for the user, as shown by step 
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24-5 in FIG. 24. This user interface 102 is a means for inputting individualized answers 
to the predetermined queries, the individualized answers relating to writing a 
personalized letter 254 regarding a product configuration that is of particular interest to 
the individual customer who is to receive the proposal. The predetermined questions 
allow the user to fill in the text entry fields with predetermined answers that correspond 
to the customer who is to receive the proposal. The personalized letter 254 information 
gathered by the letterForm object 288 may then be stored in the LetterData object 138 
which is attached to the current proposal object 110, as shown by step 24-6 in FIG. 24. 

The user may decide to generate a customized, printed proposal that includes one 
or more pages comprising the personalized letter 254. To include these personalized 
letter 254 pages, the user may select "Contents" 174 from the main menu 170 of the 
selection device 101, as shown by step 18-1 of FIG. 18. In response, the selection 
device 101 preferably sends a load message to the TableOfContentsForm object 284, as 
shown by step 18-2 of FIG. 18. On receipt of the load message, the 
TableOfContentsForm object 284 may display itself within the main window of the 
selection device 101. Upon loading itself, the TableOfContentsForm object 284 obtains 
a pointer to the proposal object 110, as shown by step 18-3 of FIG. 18. The 
TableOfContentsForm object 284 then obtains a pointer from the proposal object 110 to 
the TableOfContentsData object 130, as shown by step 18-4 of FIG. 18. The user may 
then select the desired Personalized letter 254 page from a list of pages that are available 
for inclusion in the printed proposal, as shown by step 18-5 of FIG. 18. The selected 
pages may be stored as PageDescriptionRecord 314 in a TableOfContentsData object 
130, as shown by step 18-6 of FIG. 18. These PageDescriptionRecord 314 include a 
field that contains an identifier that indicates which page layout 120 may be used to 
format each personalized letter 254 page. The page layout 120 typically determines the 
content and appearance of the final printed page. The page layouts 120 may be stored 
in the report database 106. 

To initiate the printing of the personalized letter, the user may select "Print" 178 
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from the main menu 170 of the selection device 101, as shown by step 25-1 of FIG. 25. 
In response, the selection device 101 preferably sends a print request to the report 
generator 104, as shown by step 25-2 of FIG. 25. The report generator 104 queries the 
active database 103 for successive page description records that describe the pages of the 
printed proposal, as shown by step 25-3 of FIG. 25. The active database 103 typically 
processes the request by searching the TableOfContentsData object 130 located in the 
current proposal. If the proposal is to include one or more pages comprising the 
personalized letter 254, the active database 103 typically queries the 
TableOfContentsData object 130 for the applicable PageDescriptionRecord 314. The 
TableOfContentsData object 130 returns the relevant PageDescriptionRecord 314 to the 
active database 103. The Active Database 103 may then send the relevant 
PageDescriptionRecord 314 to the report generator 104, as shown by step 25-4 in FIG. 
25. These PageDescriptionRecord 314 may include a field that contains an identifier 
that indicates which page layouts 120 may be used to format these particular letter 254 
pages. The report generator 104 queries the report database 106 for the applicable page 
layouts 120, as shown by step 25-5 in FIG. 25. The report database 106 returns the 
relevant page layouts 120 to the report generator 104, as shown by step 25-6 in FIG. 
25. 

Each page layout 120 contains formatting specifications that indicate where specific 
Personalized letter 254 information may appear on the printed page. The report 
generator 104 typically reads each format specification to determine the data required at 
that location on the page. 

If the format specifications require data relating to the personalized letter 254, the 
report generator 104 preferably queries the active database 103, as shown by step 25-7 
in FIG. 25. The active database 103 queries the LetterData object 138, locates and 
retrieves the applicable personalized letter 254 information from the LetterData object 
138, and returns this personalized letter 254 information to the report generator 104, as 
shown by step 25-8 in FIG. 25. 
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If the format specifications require static pictures or text segments, then the report 
generator 104 preferably retrieves the applicable information from the static database 
105 object, as shown by step 25-9 in FIG. 25. The static database 105 returns this 
information to the report generator 104 as shown in step 25-10 in FIG. 25. The report 
generator 104 typically repeats this process for each format specification on the page 
layout 120, which builds a personalized letter 254 page that is then sent to the printer, as 
shown by step 25-11 in FIG. 25. 

In this fashion, the report generator 104 may print one or more customized and 
individualized letter 254 pages, along with the predetermined text segments and 
pictures that correspond with the personalized letter 254 information related to a 
particular product configuration. 

The personalized letter 254 page layouts 120 may specify that the name, address and 
telephone number or other identification data of the customer appear on the letter 254 
pages. The customer information may be initially entered via the CustomerForm object 
286. (See FIG. 20). The customer information may be stored in the CustomerData 
object 136 attached to the proposal. 

The report generator 104 preferably reads format specifications from the page layout 
120 via the report database 106, as shown by step 21-1 in FIG. 21. When the particular 
formatting specification in the page layout 120 requires the customer's name, address, or 
telephone number or other identification data to be included on a printed page, the 
report generator 104 preferably sends a request to the active database 103 for the 
specified customer information, as shown by step 21-2 in FIG. 21. The active database 
103 may obtain the specified customer information from the CustomerData object 136 
stored within the current proposal object 110. The active database 103 then returns this 
information to the report generator 104, as shown by step 21-3 in FIG. 21. The report 
generator 104 typically builds the page using this information and sends it to the printer, 
as shown by step 21-4 in FIG. 21. 

The letter 254 page layouts 120 may specify that the name, address and telephone 
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number of the salesperson appear on the letter 254 pages. The salesperson information 



stored in the individual salesperson's SalesPersonData object 134 attached to the 
proposal. (See FIG. 22). The report generator 104 may read format specifications from 
the page layout 120 via the report database 106, as shown by step 23-1 in FIG. 23. 
When the particular format specifiers require the salesperson's name, address and 
telephone number to be included on a page format, the report generator 104 preferably 
sends a request to the active database 103 for the specified salesperson information, as 
shown by step 23-2 in FIG. 23. The active database 103 obtains this salesperson 
information from the SalesPersonData object 134 in the proposal and returns this 
salesperson information to the report generator 104, as shown by step 23-3 in FIG. 23. 
The report generator 104 preferably builds the page using this salesperson information 
and sends the page to the printer, as shown by step 23-4 in FIG. 23. 



When the user begins a deal with a customer, the user may want to include in the 
customized, printed proposal one or more product description pages each comprising 
predetermined pictures and text relating to features, benefits and environments of 
interest to the customer. 

The user interface 102 provides a means for presenting a series of predetermined 
queries related to features, benefits and environments of particular items of standard 
and optional equipment that may be included in the product. This product description 
information may be of interest to different potential customers who may purchase the 
product. The user interface 102 is also a means for selecting particular items of 
standard and optional equipment about which product description information should 
appear in the printed proposal. 

The user may select "Customer Information" 176 from the main menu 170 of the 



may be initially entered by the employer in the ListOfSalesPersonsData object 158 and is 



Proposal: Product Description Pages 
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selection device 101, as shown by step 26-1 in FIG. 26. The user further selects 
"Standard and Optional Equipment" from the "Customer Information" 176 menu. In 
response, the selection device 101 preferably sends a load message to the ProductForm 
object 290, as shown by step 26-2 in FIG. 26. On receipt of the load message, the 
ProductForm object 290 may display itself in a window within the main window of the 
selection device 101. Upon loading itself, the ProductForm object 290 obtains a pointer 
to a proposal object 110, as shown by step 26-3 in FIG. 26. The ProductForm object 
290 may then obtain a pointer from the proposal object 110 to a ProductData object 140, 
as shown by step 26-4 in FIG. 26. 

The ProductForm object 290 presents a user interface 102 to the user typically 
comprising text entry fields and predetermined questions for the user, as shown by step 
26-5 in FIG. 26. The predetermined questions allow the user to specify those items of 
standard and optional equipment about which features and benefits information is of 
particular interest to the customer who is to receive the proposal. The product 
description information gathered by the ProductForm object 290 may then be stored in 
the ProductData object 140 which is attached to the current proposal object 110, as 
shown by step 26-6 in FIG. 26. 

The user may decide to generate a customized, printed proposal that includes one 
or more product description pages. To include these product description pages, the user 
may select "Contents" 174 from the main menu 170 of the selection device 101, as shown 
by step 18-1 of FIG. 18. In response, the selection device 101 preferably sends a load 
message to the TableOfContentsForm object 284, as shown by step 18-2 of FIG. 18. 
On receipt of the load message, the TableOfContentsForm object 284 may display itself 
within the main window of the selection device 101. Upon loading itself, the 
TableOfContentsForm object 284 obtains a pointer to the proposal object 110, as shown 
by step 18-3 of FIG. 18. The TableOfContentsForm object 284 then obtains a pointer 
from the proposal object 110 to the TableOfContentsData object 123, as shown by step 
18-4 of FIG. 18. The user may then select the desired product description pages from a 
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list of pages that are available for inclusion in the printed proposal, as shown by step 
18-5 of FIG. 18. The selected pages may be stored as PageDescriptionRecord 314 in a 
TableOfContentsData object 123, as shown by step 18-6 of FIG. 18. These 
PageDescriptionRecord 314 typically include a field that contains an identifier that 
indicates which page layout 120 may be used to format each product description page. 
The page layout 120 preferably determines the content and appearance of the final 
printed page. The page layouts 120 are stored in the report database 106. 

To initiate the printing of the product description pages, the user may select "Print" 
178 from the main menu 170 of the selection device 101, as shown by step 27-1 of FIG. 
27. In response, the selection device 101 preferably sends a print request to the report 
generator 104, as shown by step 27-2 of FIG. 27. The report generator 104 may query 
the active database 103 for successive page description records that describe the pages of 
the printed proposal, as shown by step 27-3 of FIG. 27. The active database 103 
typically processes the request by searching the TableOfContentsData object 130 located 
in the current proposal. If the proposal is to include one or more product description 
pages comprising predetermined pictures and text related to features, benefits and 
environments of interest to the customer, the active database 103 preferably queries the 
TableOfContentsData object 130 for the applicable PageDescriptionRecord 314. The 
TableOfContentsData object 130 returns the relevant PageDescriptionRecord 314 to the 
active database 103. The active database 103 may then send the relevant 
PageDescriptionRecord 314 to the report generator 104, as shown by step 27-4 in FIG. 
27. These PageDescriptionRecord 314 may include a field that contains an identifier 
that indicates which page layouts 120 may be used to format these particular product 
description pages. The report generator 104 queries the report database 106 for the 
applicable page layouts 120, as shown by step 27-5 in FIG. 27. The report database 106 
returns the relevant page layouts 120 to the report generator 104, as shown by step 27-6 
in FIG. 27. 

Each page layout 120 preferably contains formatting specifications that indicate 
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where specific product description information may appear on the printed page. The 
report generator 104 reads each format specification to determine the data required at 
that location on the page. 

If the format specifications require data relating to the features, benefits and 
5 environments of interest to a customer, the report generator 104 preferably queries the 
active database 103 for the standard and optional equipment product description 
information, as shown by step 27-7 in FIG. 27. The active database 103 queries the 
ProductData object 140, locates and retrieves the selected items of standard and optional 
equipment from the ProductData object 140, and returns this information to the report 

10 generator 104, as shown by step 27-8 in FIG. 27. 

The report generator 104 typically retrieves the text and pictures relating to 
features, benefits and environments for items of standard and optional equipment 
selected for inclusion in the printed proposal from the static database 105 object, as 
shown by step 27-9 in FIG. 27. The static database 105 may return this information to 

15 the report generator 104, as shown by step 27-10 in FIG. 27. The report generator 104 
preferably repeats this process for each format specification on the page layout 120, 
which builds a product description page that is then sent to the printer, as shown by step 
27-11 in FIG. 27. In this fashion, the Report Generator 104 may print one or more 
customized and individualized product description pages. 

20 The product description page layout 120 may specify that the name, address and 

telephone number or other identification data of the customer appear on the product 
description pages. The customer information may be initially entered via the 
CustomerForm object 286. (See FIG. 20). The customer information may be stored in 
the CustomerData object 136 attached to the proposal. 

25 The report generator 104 reads format specifications from the page layout 120 via 

the report database 106, as shown by step 21-1 in FIG. 21. When the particular 
formatting specification in the page layout 120 requires the customer's name, address, or 
telephone number or other identification data to be included on a printed page, the 
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report generator 104 preferably sends a request to the active database 103 for the 
specified customer information, as shown by step 21-2 in FIG. 21. The active database 
103 may obtain the specified customer information from the CustomerData object 136 
stored within the current proposal object 110. The active database 103 then returns this 
information to the report generator 104, as shown by step 21-3 in FIG. 21. The report 
generator 104 typically builds the page using this information and sends it to the printer, 
as shown by step 21-4 in FIG. 21. 

The product description page layout 120 may specify that the name, address and 
telephone number of the salesperson appear on the product description pages. The 
salesperson information may be initially entered by the employer, for example, in the 
ListOfSalesPersonsData object 158 and may be stored in the individual salesperson's 
SalesPersonData object 134 attached to the proposal. (See FIG. 22). The report 
generator 104 reads format specifications from the page layout 120 via the report 
database 106, as shown by step 23-1 in FIG. 23. When the particular format specifiers 
require the salesperson's name, address and telephone number to be included on a page 
format, the report generator 104 preferably sends a request to the active database 103 
for the specified salesperson information, as shown by step 23-2 in FIG. 23. The active 
database 103 obtains this salesperson information from the SalesPersonData object 134 in 
the proposal and returns this salesperson information to the report generator 104, as 
shown by step 23-3 in FIG. 23. The report generator 104 typically builds the page using 
this salesperson information and sends the page to the printer, as shown by step 23-4 in 



When the user begins a deal with a customer, the user may want to include in the 
customized, printed proposal one or more individualized pages comprising the product 
specification which is of particular interest to the customer who is to receive the 
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proposal. 

The user interface 102 provides a means for presenting a series of predetermined 
queries related to the particular items of standard and optional equipment that may be 
included in the product specification of particular interest to a customer. The user 
interface 102 also provides a means for selecting particular items of standard and 
optional equipment to be included in the product specification of a particular product. 

The user may select "Customer Information" 176 from the main menu 170 of 
the selection device 101, as shown by step 28-1 in FIG. 28. The user may further select 
"Standard and Optional Equipment" from the "Customer Information" 176 menu. In 
response, the selection device 101 preferably sends a load message to the ProductForm 
object 290, as shown by step 28-2 in FIG. 28. On receipt of the load message, the 
ProductForm object 290 may display itself in a window within the main window of the 
selection device 101. Upon loading t itself, the ProductForm object 290 obtains a pointer 
to a proposal object 110, as shown by step 28-3 in FIG. 28. The ProductForm object 
290 then obtains a pointer from the proposal object 110 to a ProductData object 140, as 
shown by step 28-4 in FIG. 28. 

The ProductForm object 290 presents a user interface 102 to the user typically 
comprising text entry fields and predetermined questions for the user, as shown by step 
28-5 in FIG. 28. The predetermined questions allow the user to specify those items of 
standard and optional equipment to be included in the product specification of 
particular interest to the customer who is to receive the proposal. The product 
specification gathered by the ProductForm object 290 may then be stored in the 
ProductData object 140 which is attached to the current proposal object 110, as shown 
by step 28-6 in FIG. 28. 

The user may decide to generate a customized, printed proposal that includes one or 
more product specification pages. To include these product specification pages, the user 
may select "Contents" 174 from the main menu 170 of the selection device 101, as shown 
by step 18-1 of FIG. 18. In response, the selection device 101 preferably sends a load 
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message to the TableOfContentsForm object 284, as shown by step 18-2 of FIG. 18. On 
receipt of the load message, the TableOfContentsForm object 284 may display itself 
within the main window of the selection device 101. Upon loading itself, the 
TableOfContentsForm object 284 obtains a pointer to the proposal object 110, as shown 
by step 18-3 of FIG. 18. The TableOfContentsForm object 284 then obtains a pointer 
from the proposal object 110 to the TableOfContentsData object 130, as shown by step 
18-4 of FIG. 18. The user may then select the desired product specification pages from 
a list of pages that are available for inclusion in the printed proposal, as shown by step 
18-5 of FIG. 18. The selected pages may be stored as PageDescriptionRecord 314 in a 
TableOfContentsData object 130, as shown by step 18-6 of FIG. 18. These 
PageDescriptionRecord 314 typically include a field that contains an identifier that 
indicates which page layout 120 may be used to format each product specification page. 
The page layout 120 preferably determines the content and appearance of the final 
printed page. The page layout 120 may be stored in the report database 106. 

To initiate the printing of the product specification pages, the user may select 
"Print" 178 from the main menu 170 of the selection device 101, as shown by step 29-1 
of FIG. 29. In response, the selection device 101 preferably sends a print request to the 
report generator 104, as shown by step 29-2 of FIG. 29. The report generator 104 may 
query the Active Database 103 for successive page description records that describe the 
pages of the printed proposal, as shown by step 29-3 of FIG. 29. The active database 
103 preferably processes the request by searching the TableOfContentsData object 130 
located in the current proposal. If the proposal is to include one or more product 
specification pages, the active database 103 queries the TableOfContentsData object 130 
for the applicable PageDescriptionRecord 314. The TableOfContentsData object 130 
returns the relevant PageDescriptionRecord 314 to the active database 103. The active 
database 103 then sends the relevant PageDescriptionRecord 314 to the report generator 
104, as shown by step 29-4 in FIG. 29. These PageDescriptionRecord 314 may include 
a field that contains an identifier that indicates which page layout 120 may be used to 
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format these particular product specification pages. The report generator 104 queries 
the report database 106 for the applicable page layout 120, as shown by step 29-5 in 
FIG. 29. The report database 106 returns the relevant page layout 120 to the report 
generator 104, as shown by step 29-6 in FIG. 29. 

Each page layout 120 preferably contains formatting specifications that indicate 
where specific product specification information may appear on the printed page. The 
report generator 104 reads each format specification to determine the data required at 
that location on the page. 

If the format specifications require data relating to the product specification of 
interest to a customer, the report generator 104 queries the active database 103 for the 
product specification information, as shown by step 29-7 in FIG. 29. The active 
database 103 queries the ProductData object 140, locates and retrieves the product 
specification information from the froductData object 140, and returns this information 
to the report generator 104, as shown by step 29-8 in FIG. 29. 

The product specification information stored in the active database 103 may be 
linked to additional product specification information stored in the static database 105. 
The additional product specification information may include weights and prices of the 
individual items of standard and optional equipment included in the product of interest 
to the customer. 

The report generator 104 retrieves the additional product specification information 
for items of standard and optional equipment selected for inclusion in the printed 
proposal from the static database 105, as shown by step 29-9 in FIG. 29. The static 
database 105 may return this information to the report generator 104, as shown by step 
29-10 in FIG. 29. The report generator 104 preferably repeats this process for each 
format specification on the page layout 120, which builds a product specification page 
that is then sent to the printer, as shown by step 29-11 in FIG. 29. In this fashion, the 
report generator 104 may print one or more customized and individualized product 
specification pages. 
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The product specification page layout 120 may specify that the name, address and 
telephone number or other identification data of the customer appear on the product 
specification pages. The customer information may be initially entered via the 
CustomerForm object 286. (See FIG. 20). The Customer information may be stored in 
the CustomerData object 136 attached to the proposal. 

The report generator 104 may read format specifications from the page layout 120 
via the report database 106, as shown by step 21-1 in FIG. 21. When the particular 
formatting specification in the page layout 120 requires the customer's name, address, or 
telephone number or other identification data to be included on a printed page, the 
report generator 104*preferably sends a request to the active database 103 for the 
specified customer information, as shown by step 21-2 in FIG. 21. The active database 
103 obtains the specified customer information from the CustomerData object 136 stored 
within the current proposal object 110. The active database 103 then returns this 
information to the report generator 104, as shown by step 21-3 in FIG. 21. The report 
generator 104 typically builds the page using this information and sends it to the printer, 
as shown by step 21-4 in FIG. 21. 

The product specification page layout 120 may specify that the name, address and 
telephone number of the salesperson appear on the product specification pages. The 
salesperson information may be initially entered by the employer, for example, in the 
ListOfSalesPersonsData object 158 and may be stored in the individual salesperson's 
SalesPersonData object 134 attached to the proposal. (See FIG. 22). The report 
generator 104 reads format specifications from the page layout 120 via the report 
database 106, as shown by step 23-1 in FIG. 23. When the particular format specifiers 
require the salesperson's name, address and telephone number to be included on a page 
format, the report generator 104 preferably sends a request to the active database 103 
for the specified salesperson information, as shown by step 23-2 in FIG. 23. The active 
database 103 obtains this salesperson information from the SalesPersonData object 134 in 
the proposal and returns this salesperson information to the report generator 104, as 
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shown by step 23-3 in FIG. 23. The report generator 104 typically builds the page using 
this salesperson information and sends the page to the printer, as shown by step 23-4 in 
FIG. 23. 

Proposal: Performance Specification Pages 

When the user begins a deal with a customer, the user may want to include in the 
customized, printed proposal one or more individualized pages comprising the 
performance specifications that are of particular interest to the customer who is to 
receive the proposal; 

The user may decide to generate a customized, printed proposal that includes one 
or more performance specification pages 240. To include these performance 
specification pages 240, the user may select "Contents" 174 from the main menu 170 of 
the selection device 101, as shown by step 18-1 of FIG. 18. In response, the selection 
device 101 preferably sends a load message to the TableOfContentsForm object 284, as 
shown by step 18-2 of FIG. 18. On receipt of the load message, the 
TableOfContentsForm object 284 may display itself within the main window of the 
selection device 101. Upon loading itself, the TableOfContentsForm object 284 obtains 
a pointer to the proposal object 110, as shown by step 18-3 of FIG. 18. The 
TableOfContentsForm object 284 then obtains a pointer from the proposal object 110 to 
the TableOfContentsData object 130, as shown by step 18-4 of FIG. 18. The user then 
selects the desired performance specification pages 240 from a list of pages that are 
available for inclusion in the printed proposal, as shown by step 18-5 of FIG. 18. The 
selected pages are stored as PageDescriptionRecord 314 in a TableOfContentsData object 
130, as shown by step 18-6 of FIG. 18. These PageDescriptionRecord 314 include a 
field that contains an identifier that indicates which page layout 120 may be used to 
format each performance specification page 240. The page layout 120 preferably 
determines the content and appearance of the final printed page. The page layout 120 
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may be stored in the report database 106. 

To initiate the printing of the performance specification pages 240, the user may 
select "Print" 178 from the main menu 170 of the selection device 101, as shown by step 
30-1 of FIG. 30. In response, the selection device 101 preferably sends a print request 
to the report generator 104, as shown by step 30-2 of FIG. 30. The report generator 
104 queries the active database 103 for successive page description records that describe 
the pages of the printed proposal, as shown by step 30-3 of FIG. 30. The active 
database 103 processes the request by searching the TableOfContentsData object 130 
located in the current proposal. If the proposal is to include one or more performance 
specification pages 240, the active database 103 queries the TableOfContentsData object 
130 for the applicable PageDescriptionRecord 314. The TableOfContentsData object 
130 returns the relevant PageDescriptionRecord 314 to the active database 103. The 
active database 103 then sends the relevant PageDescriptionRecord 314 to the report 
generator 104, as shown by step 30-4 in FIG. 30. These PageDescriptionRecord 314 
may include a field that contains an identifier that indicates which page layout 120 may 
be used to format these particular performance specification pages 240. The report 
generator 104 queries the report database 106 for the applicable page layout 120, as 
shown by step 30-5 in FIG. 30. The report database 106 returns the relevant page 
layout 120 to the report generator 104, as shown by step 30-6 in FIG. 30. 

Each page layout 120 typically contains formatting specifications that indicate 
where specific performance specification information may appear on the printed page. 
The report generator 104 may read each format specification to determine the data 
required at that location on the page. 

If the format specifications require data relating to the performance specification of 
interest to a customer, the report generator 104 queries the active database 103 for the 
performance specification information, as shown by step 30-7 in FIG. 30. The active 
database 103 will preferably handle the process of calculating the desired performance 
specification information based on the product specification stored within itself and 
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additional performance information linked to this product information 238 and stored in 
the static database 105. The active database 103 may return this information to the 
report generator 104, as shown by step 30-8 in FIG. 30. 

If the format specifications require static pictures or text segments, then the report 
generator 104 typically retrieves the applicable information from the static database 105 
object, as shown by step 30-9 in FIG. 30. The report generator 104 may repeat this 
process for each format specification on the page layout, which builds a performance 
specification page 240 that is then sent to the printer, as shown by step 30-11 in FIG. 
30. In this fashion, the report generator 104 may print one or more customized and 
individualized performance specification pages 240. 

The performance specification page layout 120 may specify that the name, address 
and telephone number or other identification data of the customer appear on the 
performance specification pages 240. The customer information may be initially 
entered via the CustomerForm object 286. (See FIG. 20). The customer information 
may be stored in the CustomerData object 136 attached to the proposal. 

The report generator 104 typically reads format specifications from the page layout 
120 via the report database 106, as shown by step 21-1 in FIG. 21. When the 
particular formatting specification in the page layout 120 requires the customer's name, 
address, or telephone number or other identification data to be included on a printed 
page, the report generator 104 preferably sends a request to the active database 103 for 
the specified customer information, as shown by step 21-2 in FIG. 21. The active 
database 103 obtains the specified customer information from the customerData object 
136 stored within the current proposal object 110. The active database 103 then returns 
this information to the report generator 104, as shown by step 21-3 in FIG. 21. The 
report generator 104 may then build the page using this information and sends it to the 
printer, as shown by step 21-4 in FIG. 21. 

The performance specification page layout 120 may specify that the name, address 
and telephone number of the salesperson appear on the performance specification pages 
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240. The salesperson information may be initially entered by the employer in the 
ListOfSalesPersonsData object 158 and is stored in the individual salesperson's 
SalesPersonData object 134 attached to the proposal. (See FIG. 22). The report 
generator 104 reads format specifications from the page layout via the report database 
106, as shown by step 23-1 in FIG. 23. When the particular format specifiers require 
the salesperson's name, address and telephone number to be included on a page format, 
the report generator 104 preferably sends a request to the active database 103 for the 
specified salesperson information, as shown by step 23-2 in FIG. 23. The active 
database 103 obtains this salesperson information from the SalesPersonData object 134 
in the proposal and returns this salesperson information to the report generator 104, as 
shown by step 23-3 in FIG. 23. The report generator 104 typically builds the page using 
this salesperson information and sends the page to the printer, as shown by step 23-4 in 
FIG. 23. 

Proposal; Trade-in Pages 

When the user begins a deal with a customer, the customer may want to trade in a 
product, in which case, the user will typically want to include individualized trade-in 
product information pages 242 in the customized, printed proposal that will be prepared 
for the customer. 

The user interface 102 provides means for presenting a series of predetermined 
queries related to the description and appraised value of a trade-in product to be traded 
in by the individual customer who is to receive the proposal. The user interface 102 also 
provides means for inputting individualized answers to the predetermined queries, the 
individualized answers relating to the description and appraised value of a trade-in 
product to be traded in by the individual customer who is to receive the proposal. 

The user may select "Customer Information" 176 from the main menu 170 of the 
selection device 101, as shown by step 31-1 in FIG. 31. The user further selects "Trade" 



41 



# 



206 from the customer information menu. In response, the selection device 101 
preferably sends a load message to the TradeForm object 292, as shown by step 31-2 in 
FIG. 31. On receipt of the load message, the TradeForm object 292 may display itself 
in a window within the main window of the selection device 101. Upon loading itself, 
the TradeForm object 292 obtains a pointer to a proposal object 110, as shown by step 
31-3 in FIG. 31. The TradeForm object 292 then obtains a pointer from the proposal 
object 110 to a TradeData object 142, as shown by step 31-4 in FIG. 31. 

The TradeForm object 292 presents a user interface 102 to the user typically 
comprising text entry fields and predetermined questions for the user, as shown by step 
31-5 in FIG. 31. This user interface 102 allows the user to enter information regarding 
a trade-in product to be traded in by the individual customer who is to receive the 
proposal. The user may fill in various data fields with information comprising a 
description and appraised value for the trade-in product. The predetermined questions 
allow the user to select one of a list of predetermined answers that correspond to the 
trade-in product of the customer who is to receive the proposal. The trade-in 
information gathered by the TradeForm object 292 may be stored in the TradeData 
object 142 which is attached to the current proposal object 110, as shown by step 31-6 
in FIG. 31. 

The user may decide to generate a customized, printed proposal that includes one 
or more pages comprising the description and appraised value of a trade-in product. To 
include these trade-in pages, the user may select "Contents" 174 from the main menu 
170 of the selection device 101, as shown by step 18-1 of FIG. 18. In response, the 
selection device 101 preferably sends a load message to the TableOfContentsForm object 
284, as shown by step 18-2 of FIG. 18. On receipt of the load message, the 
TableOfContentsForm object 284 may display itself within the main window of the 
selection device 101. Upon loading itself, the TableOfContentsForm object 284 obtains 
a pointer to the proposal object 110, as shown by step 18-3 of FIG. 18. The 
TableOfContentsForm object 284 then obtains a pointer from the proposal object 110 to 
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the TableOfContentsData object 130, as shown by step 18-4 of FIG. 18. The user may 
then select the desired trade-in pages from a list of pages that are available for inclusion 
in the printed proposal, as shown by step 18-5 of FIG. 18. The selected pages may be 
stored as PageDescriptionRecord 314 in TableOfContentsData object 130, as shown by 
step 18-6 of FIG. 18. These PageDescriptionRecord 314 include a field that contains an 
identifier that indicates which page layout 120 may be used to format each trade-in 
page 242. The page layout 120 preferably determines the content and appearance of the 
final printed page. The page layouts 120 may be stored in the report database 106. 

To initiate the printing of the trade-in pages 242 comprising the description and 
appraised value of the trade-in product, the user may select "Print" 178 from the main 
menu 170 of the selection device 101, as shown by step 32-1 of FIG. 32. In response, 
the selection device 101 preferably sends a print request to the report generator 104, as 
shown by step 32-2 of FIG. 32. The report generator 104 queries the active database 
103 for successive page description records that describe the pages of the printed 
proposal, as shown by step 32-3 of FIG. 32. The active database 103 typically processes 
the request by searching the TableOfContentsData object 130 located in the current 
proposal. If the proposal is to include one or more pages comprising the description 
and appraised value of a trade-in product, the active database 103 queries the 
TableOfContentsData object 130 for the applicable PageDescriptionRecord 314. The 
TableOfContentsData object 130 returns the relevant PageDescriptionRecord 314 to the 
active database 103. The active database 103 then sends the relevant 
PageDescriptionRecord 314 to the report generator 104, as shown by step 32-4 in FIG. 
32. These PageDescriptionRecord 314 may include a field that contains an identifier 
that indicates which page layout may be used to format these particular trade-in pages 
242. The report generator 104 queries the report database 106 for the applicable page 
layout, as shown by step 32-5 in FIG. 32. The report database 106 returns the relevant 
page layout to the report generator 104, as shown by step 32-6 in FIG. 32. 

Each page layout may contain formatting specifications that indicate where specific 
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information regarding the description and appraised value of the trade-in product may 
appear on the printed page. The report generator 104 may read each format 
specification to determine the data required at that location on the page. 

If the format specifications require data relating to the description and appraised 
value of the trade-in product, the report generator 104 preferably queries the active 
database 103, as shown by step 32-7 in FIG. 32. The active database 103 queries the 
TradeData object 142, locates and retrieves the applicable description and appraised 
value information from the TradeData object 142, and returns this trade-in information 
to the report generator 104, as shown by step 32-8 in FIG. 32. 

If the format specifications require static pictures or text segments, then the report 
generator 104 may retrieve the applicable information from the static database 105 
object, as shown by step 32-9 in FIG. 32. The static database 105 may return this 
information to the report generator 104, as shown by step 32-10 in FIG. 32. The report 
generator 104 typically repeats this process for each format specification on the page 
layout, which builds a trade-in page 242 that may then be sent to the printer, as shown 
by step 32-11 in FIG. 32. 

In this fashion, the report generator 104 may print one or more customized and 
individualized trade-in product pages 242 which comprise the description and appraised 
value of a trade-in product, along with the predetermined text segments and pictures 
that correspond with this specified trade -in product. 

The trade-in page layout 120 may specify that the name, address and telephone 
number or other identification data of the customer appear on the trade-in pages. The 
customer information may be initially entered via the CustomerForm object 286. (See 
FIG. 20). The customer information may be stored in the CustomerData object 136 
attached to the proposal. 

The report generator 104 may read format specifications from the page layout via 
the report database 106, as shown by step 21-1 in FIG. 21. When the particular 
formatting specification in the page layout requires the customer's name, address, or 
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telephone number or other identification data to be included on a printed page, the 
report generator 104 preferably sends a request to the active database 103 for the 
specified customer information, as shown by step 21-2 in FIG. 21. The active database 

103 obtains the specified customer information from the CustomerData object 136 stored 
within the current proposal object 110. The active database 103 then returns this 
information to the report generator 104, as shown by step 21-3 in FIG. 21. The report 
generator 104 typically builds the page using this information and sends it to the printer, 
as shown by step 21-4 in FIG. 21. 

The trade-in page layout may specify that the name, address and telephone number 
of the salesperson appear on the trade-in pages. The salesperson information may be 
initially entered by the employer in the ListOfSalesPersonsData object 158 and may be 
stored in the individual salesperson's SalesPersonData object 134 attached to the 
proposal. (See FIG. 22). The report generator 104 may read format specifications from 
the page layout via the report database 106, as shown by step 23-1 in FIG. 23. When 
the particular format specifiers require the salesperson's name, address and telephone 
number to be included on a page format, the report generator 104 preferably sends a 
request to the active database 103 for the specified salesperson information, as shown by 
step 23-2 in FIG. 23. The active database 103 obtains this salesperson information from 
the SalesPersonData object 134 in the proposal and returns this salesperson information 
to the report generator 104, as shown by step 23-3 in FIG. 23. The report generator 

104 typically builds the page using this salesperson information and sends the page to 
the printer, as shown by step 23-4 in FIG. 23. 



The user interface 102 provides means for presenting a series of predetermined 
queries related to the product price quotation for a product of interest to a potential 
customer. The user interface 102 also provides means for inputting individualized 
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answers to the predetermined queries, the individualized answers relating to the product 
price quotation of a particular product configuration that is of particular interest to the 
individual customer who is to receive the proposal. 

The user may select "Customer Information" 176 from the main menu 170 of the 
selection device 101, as shown by step 33-1 in FIG. 33. The user may further select 
"Quotation" from the "Customer Information" 176 menu. In response, the selection 
device 101 preferably sends a load message to the QuotationForm object 294, as shown 
by step 33-2 in FIG. 33. On receipt of the load message, the QuotationForm object 294 
may display itself in a window within the main window of the selection device 101. 
Upon loading itself, the QuotationForm object 294 obtains a pointer to a proposal object 
110, as shown by step 33-3 in FIG. 33. The QuotationForm object 294 then obtains a 
pointer from the proposal object 110 to a QuotationData object 144, as shown by step 
33-4 in FIG. 33. 

The QuotationForm object 294 presents a user interface 102 to the user typically 
comprising text entry fields and predetermined questions for the user, as shown by step 
33-5 in FIG. 33. The user interface 102 provides means for inputting individualized 
answers to the predetermined queries, the individualized answers relating to the price 
quotation for a product configuration that is of particular interest to the individual 
customer who is to receive the proposal. The predetermined questions may allow the 
user to modify the price quotation for to a product configuration that is of particular 
interest to the customer who is to receive the proposal. The price quotation information 
gathered by the QuotationForm object 294 may then be stored in the QuotationData 
object 144 which is attached to the current proposal object 110, as shown by step 33-6 
in FIG. 33. The user may wish to compare the product price quotations of different 
product configurations. This comparison may be accomplished by repeating the process 
described above and in FIG. 33 to create multiple QuotationData objects 144. 

When the user begins a deal with a customer, the user may want to include in the 
proposal one or more individualized pages comprising the product price quotation which 
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is of particular interest to the. customer who is to receive the proposal. To include the 
product price quotation pages, the user may select "Contents" 174 from the main menu 
170 of the selection device 101, as shown by step 18-1 of FIG. 18. In response, the 
selection device 101 preferably sends a load message to the TableOfContentsForm object 
284, as shown by step 18-2 of FIG. 18. On receipt of the load message, the 
TableOfContentsForm object 284 may display itself within the main window of the 
selection device 101. Upon loading itself, the TableOfContentsForm object 284 obtains 
a pointer to the proposal object 110, as shown by step 18-3 of FIG. 18. The 
TableOfContentsForm object 284 then obtains a pointer from the proposal object 110 to 
the TableOfContentsData object 130, as shown by step 18-4 of FIG. 18. The user may 
then select the desired price quotation pages from a list of pages that are available for 
inclusion in the printed proposal, as shown by step 18-5 of FIG. 18. The selected 
pages may be stored as PageDescriptionRecord 314 in a TableOfContentsData object 
130, as shown by step 18-6 of FIG. 18. These PageDescriptionRecord 314 typically 
include a field that contains an identifier that indicates which page layout may be used 
to format each price quotation page. The page layout may determine the content and 
appearance of the final printed page. The page layout may be stored in the report 
database 106. 

To initiate the printing of the product price quotation pages, the user may select 
"Print" 178 from the main menu 170 of the selection device 101, as shown by step 34-1 
of FIG. 34. In response, the selection device 101 preferably sends a print request to the 
report generator 104, as shown by step 34-2 of FIG. 34. The report generator 104 
queries the active database 103 for successive page description records that describe the 
pages of the printed proposal, as shown by step 34-3 of FIG. 34. The active database 
103 typically processes the request by searching the TableOfContentsData object 130 
located in the current proposal. If the proposal is to include one or more product price 
quotation pages, the active database 103 queries the TableOfContentsData object 130 for 
the applicable PageDescriptionRecord 314. The TableOfContentsData object 130 returns 
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the relevant PageDescriptionRecord 314 to the active database 103. The active database 
103 then sends the relevant PageDescriptionRecord 314 to the report generator 104, as 
shown by step 34-4 in FIG. 34. These PageDescriptionRecord 314 may include a field 
that contains an identifier that indicates which page layout may be used to format these 
particular product price quotation pages. The report generator 104 queries the report 
database 106 for the applicable page layout, as shown by step 34-5 in FIG. 34. The 
report database 106 returns the relevant page layout to the report generator 104, as 
shown by step 34-6 in FIG. 34. 

Each page layout preferably contains formatting specifications that indicate where 
specific product price quotation information may appear on the printed page. The 
report generator 104 may read each format specification to determine the data required 
at that location on the page. 

If the format specifications require data relating to the product price quotation of 
interest to a customer, the report generator 104 queries the active database 103 for the 
product price quotation information, as shown by step 34-7 in FIG. 34. The active 
database 103 will preferably handle the process of calculating the desired product price 
quotation based on the product specification stored within itself and on additional price 
information stored in the static database 105 and linked to this product information 
238. The active database 103 may return this information to the report generator 104, 
as shown by step 34-8 in FIG. 34. 

If the format specifications require static pictures or text segments, then the report 
generator 104 preferably retrieves the applicable information from the static database 
105 object, as shown by step 34-9 in FIG. 34. The static database 105 may return this 
information to the report generator 104, as shown by step 34-10 in FIG. 34. The report 
generator 104 typically repeats this process for each format specification on the page 
layout, which builds a product price quotation page that is then sent to the printer, as 
shown by step 34-11 in FIG. 34. In this fashion, the report generator 104 may print 
one or more customized and individualized product price quotation pages. 
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The product price quotation page layout may specify that the name, address and 
telephone number or other identification data of the customer appear on the product 
price quotation pages. The customer information was initially entered via the 
CustomerForm object 286. (See FIG. 20). The customer information may be stored in 
the CustomerData object 136 attached to the proposal. 

The report generator 104 reads format specifications from the page layout via the 
report database 106, as shown by step 21-1 in FIG. 21. When the particular formatting 
specification in the page layout requires the customer's name, address, or telephone 
number or other identification data to be included on a printed page, the report 
generator 104 preferably sends a request to the active database 103 for the specified 
customer information, as shown by step 21-2 in FIG. 21. The active database 103 
obtains the specified customer information from the CustomerData object 136 stored 
within the current proposal object 110. The active database 103 then returns this 
information to the report generator 104, as shown by step 21-3 in FIG. 21. The report 
generator 104 typically builds the page using this information and sends it to the printer, 
as shown by step 21-4 in FIG. 21. 

The product price quotation page layout may specify that the name, address and 
telephone number of the salesperson appear on the product price quotation pages. The 
salesperson information may be initially entered by the employer in the 
ListOfSalesPersonsData object 158 and is stored in the individual salesperson's 
SalesPersonData object 134 attached to the proposal. (See FIG. 22). The report 
generator 104 reads format specifications from the product price quotation page layout 
via the report database 106, as shown by step 23-1 in FIG. 23. When the particular 
format specifiers require the salesperson's name, address and telephone number to be 
included on a page format, the report generator 104 preferably sends a request to the 
active database 103 for the specified salesperson information, as shown by step 23-2 in 
FIG. 23. The active database 103 obtains this salesperson information from the 
SalesPersonData object 134 in the proposal and returns this salesperson information to 
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the report generator 104, as shown by step 23-3 in FIG. 23. The report generator 104 
typically builds the page using this salesperson information and sends the page to the 
printer, as shown by step 23-4 in FIG. 23. 

Proposal: Finance Pages 

When the user begins a deal with a customer, the user may want to include one or 
more individualized pages which comprise the financing information to be included in 
the customized, printed proposal that will be prepared for the customer. 

The user interface 102 provides means for presenting a series of predetermined 
queries related to financing a product of interest to different potential customers who 
may purchase the product. The user interface 102 also provides means for inputting 
individualized answers to the predetermined queries, the individualized answers relating 
to the finance cost of product configurations that are of particular interest to the 
individual customer who is to receive the proposal. 

The user may select "Customer Information" 176 from the main menu 170 of the 
selection device 101, as shown by step 35-1 in FIG. 35. The user may further select 
"Payment Schedule & Terms" from the "Customer Information" 176 menu. In response, 
the selection device 101 preferably sends a load message to the FinanceForm object 296, 
as shown by step 35-2 in FIG. 35. On receipt of the load message, the FinanceForm 
object 296 may display itself in a window within the main window of the selection 
device 101. Upon loading itself, the FinanceForm object 296 obtains a pointer to a 
proposal object 110, as shown by step 35-3 in FIG. 35. The FinanceForm object 296 
then obtains a pointer from the proposal object 110 to a FinanceData object 146, as 
shown by step 35-4 in FIG. 35. 

The FinanceForm object 296 presents a user interface 102 to the user typically 
comprising text entry fields and predetermined questions for the user, as shown by step 
35-5 in FIG. 35. This user interface 102 provides means for inputting individualized 
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answers to the predetermined queries, the individualized answers relating to financing a 
product configuration that is of particular interest to the individual customer who is to 
receive the proposal. The predetermined questions allow the user to select one of a list 
of predetermined answers that correspond to the financing of a product configuration 
that is of particular interest to the customer who is to receive the proposal. The finance 
cost information gathered by the FinanceForm object 296 is then stored in the 
FinanceData object 146 which is attached to the current proposal object 110, as shown 
by step 35-6 in FIG. 35. The user may wish to compare the finance cost of different 
finance plans. This comparison may be accomplished by repeating the process described 
above and in FIG. 35 to create multiple FinanceData objects 146. 

The user may decide to generate a customized, printed proposal that includes one 
or more pages comprising the financing information. To include these finance pages, 
the user may select "Contents" 174 from the main menu 170 of the selection device 101, 
as shown by step 18-1 of FIG. 18. In response, the selection device 101 preferably 
sends a load message to the TableOfContentsForm object 284, as shown by step 18-2 of 
FIG. 18. On receipt of the load message, the TableOfContentsForm object 284 may 
display itself within the main window of the selection device 101. Upon loading itself, 
the TableOfContentsForm object 284 obtains a pointer to the proposal object 110, as 
shown by step 18-3 of FIG. 18. The TableOfContentsForm object 284 then obtains a 
pointer from the proposal object 110 to the TableOfContentsData object 130, as shown 
by step 18-4 of FIG. 18. The user may then select the desired finance pages from a list 
of pages that are available for inclusion in the printed proposal, as shown by step 18-5 
of FIG. 18. The selected pages may be stored as PageDescriptionRecord 314 in a 
TableOfContentsData object 130, as shown by step 18-6 of FIG. 18. These 
PageDescriptionRecord 314 include a field that contains an identifier that indicates 
which page layout may be used to format each finance page. The page layout may 
determine the content and appearance of the final printed page. The page layout may 
be stored in the report database 106. 
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To initiate the printing of the Finance pages, the user may select "Print" 178 from 
the main menu 170 of the selection device 101, as shown by step 36-1 of FIG. 36. In 
response, the selection device 101 preferably sends a print request to the report 
generator 104, as shown by step 36-2 of FIG. 36. The report generator 104 queries the 
active database 103 for successive page description records that describe the pages of the 
printed proposal, as shown by step 36-3 of FIG. 36. The active database 103 typically 
processes the request by searching the TableOfContentsData object 130 located in the 
current proposal. If the proposal is to include one or more pages comprising the 
financing information of a product configuration, the active database 103 may query the 
TableOfContentsData object 130 for the applicable PageDescriptionRecord 314. The 
TableOfContentsData object 130 returns the relevant PageDescriptionRecord 314 to the 
active database 103. The active database 103 then sends the relevant 
PageDescriptionRecord 314 to the report generator 104, as shown by step 36-4 in FIG. 
36. These PageDescriptionRecord 314 may include a field that contains an identifier 
that indicates which page layout may be used to format these particular finance pages. 
The report generator 104 queries the report database 106 for the applicable page 
layouts 120, as shown by step 36-5 in FIG. 36. The report database 106 returns the 
relevant page layouts 120 to the report generator 104, as shown by step 36-6 in FIG. 36. 

Each page layout preferably contains formatting specifications that indicate where 
specific finance information may appear on the printed page. The report generator 104 
reads each format specification to determine the data required at that location on the 
page. 

If the format specifications require data relating to the financing of a product 
configuration, the report generator 104 queries the active database 103, as shown by 
step 36-7 in FIG. 36. The active database 103 queries the FinanceData object 146, 
locates and retrieves the applicable financing information from the FinanceData object 
146, and returns this financing information to the report generator 104, as shown by 
step 36-8 in FIG. 36. 
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If the format specifications require static pictures or text segments, then the report 
generator 104 preferably retrieves the applicable information from the static database 
105 object, as shown by step 36-9 in FIG. 36. The static database 105 will typically 
return this information to the report generator 104, as shown by step 36-10 in FIG. 36. 
The report generator 104 preferably repeats this process for each format specification on 
the page layout, which builds a finance page that is then sent to the printer, as shown by 
step 36-11 in FIG. 36. 

In this fashion, the report generator 104 may print one or more customized and 
individualized finance pages, along with the predetermined text segments and pictures 
that correspond with' the financing information related to a particular product 
configuration. 

The finance page layouts 120 may specify that the name, address and telephone 
number or other identification data of the customer appear on the finance pages. The 
customer information may be initially entered via the CustomerForm object 286. (See 
FIG. 20). The customer information may be stored in the CustomerData object 136 
attached to the proposal. 

The report generator 104 reads format specifications from the page layout via the 
report database 106, as shown by step 21-1 in FIG. 21. When the particular formatting 
specification in the page layout requires the customer's name, address, or telephone 
number or other identification data to be included on a printed page, the report 
generator 104 preferably sends a request to the active database 103 for the specified 
customer information, as shown by step 21-2 in FIG. 21. The active database 103 
obtains the specified customer information from the CustomerData object 136 stored 
within the current proposal object 110. The active database 103 then returns this 
information to the report generator 104, as shown by step 21-3 in FIG. 21. The report 
generator 104 typically builds the page using this information and sends it to the 
printer, as shown by step 21-4 in FIG. 21. 

The finance page layouts 120 may specify that the name, address and telephone 
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number of the salesperson appear on the finance pages. The salesperson information 
may be initially entered by the employer in the ListOfSalesPersonsData object 158 and 
may be stored in the individual salesperson's SalesPersonData object 134 attached to the 
proposal. (See FIG. 22). The report generator 104 reads format specifications from the 
page layout via the report database 106, as shown by step 23-1 in FIG. 23. When the 
particular format specifiers require the salesperson's name, address and telephone 
number to be included on a page format, the report generator 104 preferably sends a 
request to the active database 103 for the specified salesperson information, as shown by 
step 23-2 in FIG. 23. The active database 103 obtains this salesperson information from 
the SalesPersonData object 134 in the proposal and returns this salesperson information 
to the report generator 104, as shown by step 23-3 in FIG. 23. The report generator 
104 typically builds the page using this salesperson information and sends the page to 
the printer, as shown by step 23-4 in FIG. 23. 



Proposal: Life cycle Pages 



When the user begins a deal with a customer, the user may want to include one or 
more individualized Economics pages 248 which comprise the life cycle cost information 
to be included in the customized, printed proposal that will be prepared for the 
customer. 

The user interface 102 provides means for presenting a series of predetermined 
queries related to the life cycle cost of product configurations that are of interest to 
different potential customers who may purchase the product. The user interface 102 
also provides means for inputting individualized answers to the predetermined queries, 
the individualized answers relating to the life cycle cost of product configurations that 
are of particular interest to the individual customer who is to receive the proposal. 

The user may select "Customer Information" 176 from the main menu 170 of the 
selection device 101, as shown by step 37-1 in FIG. 37. The user may further select 
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"Economies'* 212 from the "Customer Information" 176 menu. In response, the selection 
device 101 preferably sends a load message to the LifeCycleForm object 298, as shown 
by step 37-2 in FIG. 37. On receipt of the load message, the LifeCycleForm object 298 
may display itself in a window within the main window of the selection device 101. 
Upon loading itself, the LifeCycleForm object 298 obtains a pointer to a proposal object 
110, as shown by step 37-3 in FIG. 37. The LifeCycleForm object 298 then obtains a 
pointer from the proposal object 110 to a LifeCycleData object 148, as shown by step 
37-4 in FIG. 37. 

The LifeCycleForm object 298 presents a user interface 102 to the user typically 
comprising text entry fields and predetermined questions for the user, as shown by step 
37-5 in FIG. 37. This user interface 102 provides means for inputting individualized 
answers to the predetermined queries, the individualized answers relating to the life 
cycle cost of a product configuration that is of particular interest to the individual 
customer who is to receive the proposal. The predetermined questions allow the user to 
select one of a list of predetermined answers that correspond to the life cycle cost 
relating to a product configuration that is of particular interest to the customer who is to 
receive the proposal. The life cycle cost information gathered by the LifeCycleForm 
object 298 is then stored in the LifeCycleData object 148 which is attached to the 
current proposal object 110, as shown by step 37-6 in FIG. 37. The user may wish to 
compare the life cycle costs of different product configurations. This comparison may 
be accomplished by repeating the process described above and in FIG. 37 to create 
multiple LifeCycleData objects 148. 

The user may decide to generate a customized, printed proposal that includes one 
or more Economics pages 248 comprising the life cycle cost. To include these life cycle 
Economics pages 248, the user may select "Contents" 174 from the main menu 170 of the 
selection device 101, as shown by step 18-1 of FIG. 18. In response, the selection 
device 101 preferably sends a load message to the TableOfContentsForm object 284, as 
shown by step 18-2 of FIG. 18. On receipt of the load message, the 
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TableOfContentsForm object 284 may display itself within the main window of the 
selection device 101. Upon loading itself, the TableOfContentsForm object 284 obtains 
a pointer to the proposal object 110, as shown by step 18-3 of FIG. 18. The 
TableOfContentsForm object 284 then obtains a pointer from the proposal object 110 to 
the TableOfContentsData object 130, as shown by step 18-4 of FIG. 18. The user then 
selects the desired life cycle pages, Economics 248, from a list of pages that are 
available for inclusion in the printed proposal, as shown by step 18-5 of FIG. 18. The 
selected pages may be stored as PageDescriptionRecord 314 in a TableOfContentsData 
object 130, as shown by step 18-6 of FIG. 18. These PageDescriptionRecord 314 
typically include a field that contains an identifier that indicates which page layout may 
be used to format each Economics 248 page. The page layout may determine the 
content and appearance of the final printed page. The page layouts 120 may be stored 
in the report database 106. 

To initiate the printing of the life cycle economics pages 248, the user may select 
"Print" 178 from the main menu 170 of the selection device 101, as shown by step 38-1 
of FIG. 38. In response, the selection device 101 preferably sends a print request to the 
report generator 104, as shown by step 38-2 of FIG. 38. The report generator 104 
queries the active database 103 for successive page description records that describe the 
pages of the printed proposal, as shown by step 38-3 of FIG. 38. The active database 
103 typically processes the request by searching the TableOfContentsData object 130 
located in the current proposal. If the proposal is to include one or more pages 
comprising the life cycle cost of a product configuration, the active database 103 queries 
the TableOfContentsData object 130 for the applicable PageDescriptionRecord 314. The 
TableOfContentsData object 130 returns the relevant PageDescriptionRecord 314 to the 
active database 103. The active database 103 then sends the relevant 
PageDescriptionRecord 314 to the report generator 104, as shown by step 38-4 in FIG. 
38. These PageDescriptionRecord 314 may include a field that contains an identifier 
that indicates which page layouts 120 may be used to format these particular life cycle 
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pages. The report generator 104 queries the report database 106 for the applicable page 
layouts 120, as shown by step 38-5 in FIG. 38. The report database 106 returns the 
relevant page layouts 120 to the report generator 104, as shown by step 38-6 in FIG. 38. 

Each page layout preferably contains formatting specifications that indicate where 
specific life cycle information may appear on the printed page. The report generator 

104 may read each format specification to determine the data required at that location 
on the page. 

If the format specifications require data relating to the life cycle of a product 
configuration, the report generator 104 preferably queries the active database 103, as 
shown by step 38-7 in FIG. 38. The active database 103 queries the LifeCycleData 
object 148, locates and retrieves the applicable life cycle information from the 
LifeCycleData object 148, and returns this life cycle information to the report 
generator 104, as shown by step 38-8 in FIG. 38. 

If the format specifications require static pictures or text segments, then the report 
generator 104 preferably retrieves the applicable information from the static database 

105 object, as shown by step 38-9 in FIG. 38. The static database 105 may return this 
information to the report generator 104, as shown by step 38-10 in FIG. 38. The report 
generator 104 typically repeats this process for each format specification on the page 
layout, which builds a life cycle page that is then sent to the printer, as shown by step 
38-11 in FIG. 38. 

In this fashion, the report generator 104 may print one or more customized and 
individualized life cycle pages, along with the predetermined text segments and pictures 
that correspond with this specified life cycle cost of a product configuration. 

The life cycle page layouts 120 may specify that the name, address and telephone 
number or other identification data of the customer appear on the life cycle pages. The 
customer information may be initially entered via the CustomerForm object 286. (See 
FIG. 20). The customer information may be stored in the CustomerData object 136 
attached to the proposal. 
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The report generator 104 reads format specifications from the page layouts 120 via 
the report database 106, as shown by step 21-1 in FIG. 21. When the particular 
formatting specification in the page layout requires the customer's name, address, or 
telephone number or other identification data to be included on a printed page, the 
report generator 104 preferably sends a request to the active database 103 for the 
specified customer information, as shown by step 21-2 in FIG. 21. The active database 
103 obtains the specified customer information from the CustomerData object 136 stored 
within the current proposal object 110. The active database 103 then returns this 
information to the report generator 104, as shown by step 21-3 in FIG. 21. The report 
generator 104 typically builds the page using this information and sends it to the printer, 
as shown by step 21-4 in FIG. 21. 

The life cycle page layouts 120 may specify that the name, address and telephone 
number of the salesperson appear on the life cycle pages. The salesperson information 
may be initially entered by the employer in the ListOfSalesPersonsData object 158 and 
may be stored in the individual salesperson's SalesPersonData object 134 attached to the 
proposal. (See FIG. 22). The report generator 104 reads format specifications from the 
page layout via the report database 106, as shown by step 23-1 in FIG. 23. When the 
particular format specifiers require the salesperson's name, address and telephone 
number to be included on a page format, the report generator 104 preferably sends a 
request to the active database 103 for the specified salesperson information, as shown by 
step 23-2 in FIG. 23. The active database 103 obtains this salesperson information from 
the SalesPersonData object 134 in the proposal and returns this salesperson information 
to the report generator 104, as shown by step 23-3 in FIG. 23. The report generator 104 
typically builds the page using this salesperson information and sends the page to the 
printer, as shown by step 23-4 in FIG. 23. 
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Proposal: Table of Contents Page 



When the user begins a deal with a customer, the user may want to include in the 
proposal a Table of Contents 252 page as part of the proposal. To include the Table of 
Contents 252 page, the user may select "Contents" 174 from the main menu 170 of the 
selection device 101, as shown by step 18-1 of FIG. 18. In response, the selection 
device 101 preferably sends a load message to the TableOfContentsForm object 284, as 
shown by step 18-2 of FIG. 18. On receipt of the load message, the 
TableOfContentsForm object 284 may display itself within the main window of the 
selection device 101.* Upon loading itself, the TableOfContentsForm object 284 obtains 
a pointer to the proposal object 110, as shown by step 18-3 of FIG. 18. The 
TableOfContentsForm object 284 then obtains a pointer from the proposal object 110 to 
the TableOfContentsData object 130, as shown by step 18-4 of FIG. 18. The user may 
then select the "Table of Contents" page from a list of pages that are available for 
inclusion in the printed proposal, as shown by step 18-5 of FIG. 18. The selected page 
may be stored as a PageDescriptionRecord 314 in a TableOfContentsData object 130, as 
shown by step 18-6 of FIG. 18. In other words, the PageDescription record for the 
"Table Of Contents" page is stored in the TableOfContentsData object 130, as it is one of 
the pages to be printed in the proposal. These PageDescriptionRecord 314 typically 
include a field that contains an identifier that indicates which page layout may be used 
to format each price quotation page. The page layout may determine the content and 
appearance of the final printed page. The page layout may be stored in the report 
database 106. 

To initiate the printing of the Table of Contents 252 page, the user may select 
"Print" 178 from the main menu 170 of the selection device 101, as shown by step 39-1 
of FIG. 39. In response, the selection device 101 preferably sends a print request to the 
report generator 104, as shown by step 39-2 of FIG. 39. The report generator 104 
queries the active database 103 for successive page description records that describe the 
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pages of the printed proposal, as shown by step 39-3 of FIG. 39. The active database 
103 processes the request by searching the TableOfContentsData object 130 located in 
the current proposal. If the proposal is to include a Table of Contents 252 page, the 
active database 103 queries the TableOfContentsData object 130 for the applicable 
PageDescriptionRecord 314. The TableOfContentsData object 130 returns the relevant 
PageDescriptionRecord 314 to the active database 103. The active database 103 then 
sends the relevant PageDescriptionRecord 314 to the report generator 104, as shown by 
step 39-4 in FIG. 39. These PageDescriptionRecord 314 may include a field that 
contains an identifier that indicates which page layout may be used to format the Table 
of Contents 252 page. The report generator 104 queries the report database 106 for the 
applicable page layouts 120, as shown by step 39-5 in FIG. 39. The report database 106 
returns the relevant page layouts 120 to the report generator 104, as shown by step 39-6 
in FIG. 39. 

Each page layout preferably contains formatting specifications that indicate where 
specific Table of Contents 252 information may appear on the printed page. The report 
generator 104 reads each format specification to determine the data required at that 
location on the page. 

If the format specifications require data relating to the Table of Contents 196 of the 
proposal, the report generator 104 queries the active database 103 for the Table of 
Contents 196 information, as shown by step 39-7 in FIG. 39. The active database 103 
preferably retrieves the Table of Contents 196 information from the 
TableOfContentsData object 130 and return this information to the report generator 
104, as shown by step 39-8 in FIG. 39. 

If the format specifications require static pictures or text segments, then the report 
generator 104 preferably retrieves the applicable information from the static database 
105 object, as shown by step 39-9 in FIG. 39. The static database 105 may return this 
information to the report generator 104, as shown by step 39-10 in FIG. 39. The report 
generator 104 typically repeats this process for each format specification on the page 
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layout 120, which builds a Table of Contents 252 page that is then sent to the printer, as 
shown by step 39-11 in FIG. 39. In this fashion, the report generator 104 may print 
one or more customized and individualized Table of Contents 2S2 pages. 

The Table of Contents 252 page layouts 120 may specify that the name, address and 
5 telephone number or other identification data of the customer appear on the Table of 
Contents 252 pages. The customer information may be initially entered via the 
CustomerForm object 286. (See FIG. 20). The customer information may be stored in 
the CustomerData object 136 attached to the proposal. 

The report generator 104 reads format specifications from the page layout 120 via 

10 the report database 106, as shown by step 21-1 in FIG. 21. When the particular 

formatting specification in the page layout 120 requires the customer's name, address, or 
telephone number or other identification data to be included on a printed page, the 
report generator 104 preferably sends a request to the active database 103 for the 
specified customer information, as shown by step 21-2 in FIG. 21. The active database 

15 103 obtains the specified customer information from the CustomerData object 136 stored 
within the current proposal object 110. The active database 103 then returns this 
information to the report generator 104, as shown by step 21-3 in FIG. 21. The report 
generator 104 typically builds the page using this information and sends it to the 
printer, as shown by step 21-4 in FIG. 21. 

20 The Table of Contents 252 page layouts may specify that the name, address and 

telephone number of the salesperson appear on the Table of Contents 252 pages. The 
salesperson information may be initially entered by the employer in the 
ListOfSalesPersonsData object 158 and stored in the individual salesperson's 
SalesPersonData object 134 attached to the proposal. (See FIG. 22). The report 

25 generator 104 reads format specifications from the Table of Contents 252 page layout 
120 via the report database 106, as shown by step 23-1 in FIG. 23. When the particular 
format specifiers require the salesperson's name, address and telephone number to be 
included on a page format, the report generator 104 preferably sends a request to the 
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active database 103 for the specified salesperson information, as shown by step 23-2 in 
FIG. 23. The active database 103 obtains this salesperson information from the 
SalesPersonData object 134 in the proposal and returns this salesperson information to 
the report generator 104, as shown by step 23-3 in FIG. 23. The report generator 104 
typically builds the page using this salesperson information and sends the page to the 
printer, as shown by step 23-4 in FIG. 23. 

Proposal: Trademark 

The system may also print a trademark identifying the product on at least one of the 
pages of the customized printed proposal. If a trademark is to appear on a page, the 
page layout 120 for that page will preferably contain a format specification that 
specifies the trademark and its location on the page. The report generator 104 queries 
the report database 106 for each page layout 120, as shown by step 40-1 in FIG. 40. 
The report database 106 returns each page layout 120, as shown by step 40-2 in FIG. 
40. If the page layout 120 contains a format specification requiring a trademark picture, 
then the report generator 104 may retrieve the trademark picture from the static 
database 105 object, as shown by step 40-3 in FIG. 40. The static database 105 may 
return this picture to the report generator 104, as shown by step 40-4 in FIG. 40. The 
report generator 104 may include the trademark picture when it builds the page to be 
printed. The report generator 104 typically builds the page using this information and 
sends it to the printer, as shown by step 40-5 in FIG. 40. 

Proposal: Printing Language 

The user interface 102 provides means for presenting a series of predetermined 
queries related to the language in which the user interface 102 should be presented. In 
addition, the user interface 102 provides means for presenting a series of predetermined 

62 



queries related to the language in which the proposal should be printed. The user 
interface 102 is also a means for inputting individualized answers to the predetermined 
queries, the individualized answers relating to the language of choice for the user 
interface 102 presentation and for the printed proposal. 

The user may select customized menu selection 177 from the main menu 170 of 
the selection device 101, as shown by step 41-1 in FIG. 41. The user may further select 
"International" from the customized menu selection 177. In response, the selection 
device 101 preferably sends a load message to the LanguageForm object 304, as shown 
by step 41-2 in FIG. 41. On receipt of the load message, the LanguageForm object 304 
may display itself in "a window within the main window of the selection device 101. 
Upon loading itself, the LanguageForm object 304 obtains a pointer to a customized 
database 114, as shown by step 41-3 in FIG. 41. The LanguageForm object 304 then 
obtains a pointer from the customized database 114 to a LanguageData object 160, as 
shown by step 41-4 in FIG. 41. 

The LanguageForm object 304 presents a user interface 102 to the user typically 
comprising text entry fields and predetermined questions for the user, as shown by step 
41-5 in FIG. 41. This user interface 102 provides means for inputting individualized 
answers to the predetermined queries, the individualized answers relating to the 
language for presenting the user interface 102 and the language for printing the 
proposal. The language information gathered by the LanguageForm object 304 may 
then be stored in the LanguageData object 160 which is attached to the customized 
database 114, as shown by step 41-6 in FIG. 41. 

The user interface 102 may further comprise means for displaying forms in any one 
of a plurality of languages. Upon receiving a load message, a form may query the 
LanguageData object 160 in the customized database 114 in the active database 103 to 
determine the language in which it should display itself. The form may then display 
itself in the specified language. 

The system may also generate the printed proposal in any one of a plurality of 
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languages. Upon receiving a print message, the report generator 104 may query the 
LanguageData object 160 in the customized database 114 in the active database 103 to 
determine the language in which it should print the proposal. The report generator 104 
will then preferably query the static database 105 for pictures and text that are in the 
appropriate language. The report generator 104 typically builds each page using pictures 
and text in the specified language and sends it to the printer. 



The user may decide to generate a customized, printed proposal that includes a 
Signature page as part of the proposal. To include this Signature page, the user may 
select "Contents" 174 from the main menu 170 of the selection device 101, as shown by 
step 18-1 of FIG. 18. In response, the selection device 101 preferably sends a load 
message to the TableOfContentsForm object 284, as shown by step 18-2 of FIG. 18. 
On receipt of the load message, the TableOfContentsForm object 284 may display itself 
within the main window of the selection device 101. Upon loading itself, the 
TableOfContentsForm object 284 obtains a pointer to the proposal object 110, as shown 
by step 18-3 of FIG. 18. The TableOfContentsForm object 284 then obtains a pointer 
from the proposal object 110 to the TableOfContentsData object 130, as shown by step 
18-4 of FIG. 18. The user may then select the desired Signature page from a list of 
pages that are available for inclusion in the printed proposal, as shown by step 18-5 of 
FIG. 18. The selected page may be stored as a PageDescription record in 
TableOfContentsData object 130, as shown by step 18-6 of FIG. 18. This 
PageDescription record preferably includes a field that contains an identifier that 
indicates which page layout 120 may be used to format the Signature page. The page 
layout 120 may determine the content and appearance of the final printed page. The 
page layouts 120 may be stored in the StaticData object, accessible through the report 
database 106. 



Proposal: Signature Page 
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To initiate the printing of the Signature page, the user may select "Print" 178 from 
the main menu 170 of the selection device 101, as shown by step 42-1 of FIG. 42. In 
response, the selection device 101 preferably sends a print request to the report 
generator 104, as shown by step 42-2 of FIG. 42. The report generator 104 queries the 
active database 103 for successive page description records that describe the pages of the 
printed proposal, as shown by step 42-3 of FIG. 42. The active database 103 processes 
the request by searching the TableOfContentsData object 130 located in the current 
proposal. 

If the proposal is to include a Signature page, the active database 103 queries the 
TableOfContentsData object 130 for the applicable PageDescription record. The 
TableOfContentsData object 130 returns the relevant PageDescription record to the 
active database 103. The active database 103 then sends the relevant PageDescription 
record to the report generator 104, as shown by step 42-4 in FIG. 42. 

This PageDescription record may include a field that contains an identifier that 
indicates which page layout 120 may be used to format this particular Signature page. 
The report generator 104 queries the report database 106 for the applicable page layout 
120, as shown by step 42-5 in FIG. 42. The report database 106 returns the relevant 
page layout 120 to the report generator 104, as shown by step 42-6 in FIG. 42. 

The page layout 120 preferably contains formatting specifications that indicate 
where specific information may appear on the printed page. The report generator 104 
reads each format specification to determine the data required at that location on the 
page. The report generator 104 typically repeats this process for each format 
specification in the page layout 120. 

The Signature page layout 120 may specify that the customers name, address, 
telephone number or other identification data is to appear on the Signature page. If the 
format specification in the page layout 120 requires the customer's name, address, 
telephone number or other identification data, the report generator 104 sends a request 
to the active database 103 for the specified customer information, as shown by step 42- 
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7 in FIG. 42. The active database 103 obtains the specified customer information from 
the CustomerData object 136 stored within the current proposal object 110. The active 
database 103 then returns this information to the report generator 104, as shown by step 
42-8 in FIG. 42. 

The Signature page layout 120 may specify that the name, address and telephone 
number or other identification data of the salesperson is to appear on the Signature page. 
If the format specification specifies the salesperson's name, address and telephone 
number, or other identification data, the report generator 104 sends a request to the 
active database 103 for the specified salesperson information, as shown by step 42-9 in 
FIG. 42. The active* database 103 obtains this salesperson information from the 
SalesPersonData object 134 in the proposal and returns this salesperson information to 
the report generator 104, as shown by step 42-10 in FIG. 42. 

If the format specifications require static pictures or text segments, then the report 
generator 104 preferably requests the applicable information from the static database 
105, as shown by step 42-11 in FIG. 42. The static database 105 returns the requested 
information to the report generator 104, as shown in step 42-12 in FIG. 42. The report 
generator 104 repeats this process for each format specification on the page layout 120, 
which builds a signature page that is then sent to the printer, as shown by step 42-13 in 
FIG. 42. 

In this fashion, the report generator 104 may print a customized and individualized 
signature page, along with any predetermined text segments and pictures that may relate 
to the product configuration that is of particular interest to the customer who is to 
receive the proposal. 

While the present invention has been described in connection with the preferred 
embodiment thereof, it will be understood that many modifications will be readily 
apparent to those skilled in the art, and this application is intended to cover any 
adaptations or variations thereof. It is manifestly intended that this invention be limited 
only by the claims and equivalents thereof. 
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